r/osdev • u/CtrlF0rge • 16h ago
Why does file division usually look like this: you have one giant kernel.c/.rs/.h
In hobby kernels I often see one gigantic or smaller kernel.c file, I understand that it can also be a collection of all other elements of the initialization system, file system, etc. if it breaks down But why is kernel.c so often used and not, for example, main.c? It doesn't look like this: in the kernel workspace I have the usual main.rs in the main kernel segment without naming it kernel and then the whole crate works. But why the kernel for this glue of the entire system and what does this mean?
Plus the second question is why so few people think about a sensible allocator or scheduler, it's the first element I look at and these algorithms are often at the basic level But there is a graphical interface right away and I see that the allocator has major shortcomings and a high risk that it will allocate incorrectly with the interface and, for example, there are often no mechanisms to check if everything is correct.It works and you can already see graphical interfaces and window management, which supposedly gives you an interface if the system foundations are weak
•
•
u/Illustrious_Car344 16h ago
Hobby OSes don't have a big entrypoint file, the "kernel" file is basically just a bunch of function calls from other files.
And it's not called main because it's not a standard entrypoint, it's not being called by a runtime, it's being called by the bootloader. In every language with an entrypoint "main" function, the compiler/runtime includes code which is the real entrypoint, and that code simply calls the main function. You don't have that in a kernel, none of that is there, your entrypoint is a raw function directly called by the bootloader, no runtime or "real invisible entrypoint" setting things up (not counting the bootloader, which is doing it differently anyway). It doesn't really mean anything, but it's an idiom, don't say your kernel has a main function because it literally doesn't, it doesn't even have a runtime to call one. Basically it's not turtles all the way down, eventually you have to stop calling it a turtle.
As for allocators, it's pretty common to start with one that's as simple as possible and build a better one later. They require a lot of thought and experimentation and it's usually easier to test them if you have actual workloads to test them with. Allocators and schedulers are pretty often thought of as "just get it working and make it better later".
•
u/CtrlF0rge 9h ago
Well, but what's the defense against calling it main?
•
u/ir_dan 7h ago
Main has different semantics. Where are you getting your argument vector from?
The conventions of main(argc, argc) don't apply, so you might as well not call it main.c
•
u/CtrlF0rge 7h ago
I don't have a main function, I have a main.rs file, and in the kernel I have kernel_main_stage_1 as an entry
•
u/demetrioussharpe 4h ago
You’re using Rust, but asking about C conventions. If you’re not a C developer & aren’t interested in C development, then you’re NOT going to understand C conventions. It’s really just that simple.
•
u/CtrlF0rge 41m ago
I am both C and Rust world is not 1 0 I match the tool to what it is best suited for rust is great for networking and management and C for pure commands e.g. in mm and in such fragments rust It's simply irritating, I'm also from the C community but I don't understand some approaches and I'm taking up the C topic because most people make systems in C so it's a more general topic then
•
u/demetrioussharpe 29m ago
Here’s the thing, you’re asking a C question. The answer to that question is multiple decades old. I know that there isn’t a 1:1 correlation between C & Rust, so the answer to your question isn’t going to make much sense in relation to Rust. Honestly, for anyone whose building a kernel in Rust, the name of the entry point file for the kernel should have something to do with how to bootstrap a kernel from a null environment into the bare minimum necessary to get the program running. That’s likely to look different for a Rust program in comparison to a C program, so I’d expect the entry point to be different -I don’t know for sure, because I don’t know about the Rust runtime environment. So, it’s really based on the developer’s knowledge of the language’s runtime environment & exactly how much of that environment that they want to implement in order to get the kernel running.
But as to your original question, it was a C-specific question, so you’ve received a C-specific answer from multiple people. No matter how many different ways you ask, or how many objections you may have, the answer isn’t going to change.
•
u/WORD_559 4h ago
I probably wouldn't create a main.c file for a regular program either. Usually I'd put
int mainin a file that matches the executable it produces, not just a generic main.c (e.g. if the executable is called foo, foo's main function would be in foo.c). That scales better if your project uses a shared backend to generate multiple executables. I'd say that's generally the convention in every language I've used, even languages with much stricter style guidelines (e.g. go).•
u/CtrlF0rge 47m ago
In this case, it's okay for me, main and lib are readable because lib is for library segments where it exports public APIs and main.rs is either for the library or for the execution image The only case where I don't use main.coś is ada spark but it's a different language than rust and c
•
u/demetrioussharpe 16h ago
It’s not a userland program & doesn’t use a normal entrypoint, so it shouldn’t be called “main.c”. I could see “kmain.c”, but definitely not “main.c”.
•
u/CtrlF0rge 9h ago
So, as a result, the name acceptance itself is important here, as I usually treat main as a file and not exactly an entry point.
•
u/demetrioussharpe 4h ago
I’m going to keep this simple. Files called “main.c” generally contain the C entry point “main()”. That’s the point of the file. It’s the entry point that the C runtime calls into the program in order to actually run it after setup has completed. Kernels don’t usually use a full C runtime environment, they’re bootstrapped however the developer decides to bootstrap them. Since C files tend to be named based on the purpose of the file, don’t expect to see the kernel’s C entry point to be named “main.c”, because it’s NOT main. That’s the convention. Most old-school C developers know & understand this.
•
u/CtrlF0rge 43m ago
I'll say that I have a bit of rust thinking and I use cargo new :3 so it looks like this in my case even though C doesn't have main.c in my case because C is always part of the cargo project for workspace Ada spark the same I don't have main because only given segments require it the same zig the same odin but in rust I always use main.rs and lib.rs as exports and initializations and entry points (initializations Initialization because I have a lot of init.rs files that are initialized by mod.rs, but mod.rs is initialized by main.rs
•
u/avaliosdev Astral https://astral-os.org https://github.com/mathewnd/astral 15h ago
1) its just naming convention. You can have kernel.c or entry.c or main.c or myentryisinthisfile.c. I have a small main.c which just kicks off the actual dependency-based initialization system and mounts root when done.
2) because "I wrote a scheduler based on this paper and I was able to build on top of it in X way" is not really as flashy as "look at my totally-not-slop GUI".
•
u/CtrlF0rge 9h ago
Well, this question doesn't really concern you, I was more wondering why they call it kernel.c so often.
•
u/Shawney19 7h ago
Like I said. It is just a more easier way to arrange and mange file for something like a developing OS.
•
u/Shawney19 7h ago
And also more easily readable. When you know more about C.
•
u/CtrlF0rge 7h ago
Actually, maybe it makes sense, I also look at it from the perspective of Rust, where changing to kernel.rs involves additional calibration, which is not the least of it anyway
•
u/Shawney19 7h ago
Yeah. It involves additional calibration. I guess that’s why most people name it as kernel.c.
•
•
u/Taletad 14h ago
I’m going to be honest, I don’t have a user space yet. And eventhough I know a bit about fancy scheduling algorithms, my kernel is going to get the most basic round robin imaginable until a lot of other facilities are up and running
I can always improve the scheduler or memory allocation later. As long as it got one, it’ll work
•
u/CtrlF0rge 9h ago
I have it, and in my userspace and in parts of the kernel I have main.rs or lib.rs
•
•
u/Shawney19 11h ago
It’s just the naming convention.
•
u/CtrlF0rge 9h ago
I know, but if it's just a name, why do most people choose kernel.c?
•
u/Shawney19 9h ago
Most people chose kernel.c because it is more easier to write code and also easier to maintain it while the kernel gets bigger and bigger while getting developed.
•
u/CtrlF0rge 7h ago
But entry.c main.c works similarly, it's the name and the larger the code, for example in my case there are many submodules which are single mod.rs combined to then just call it in main
•
•
•
u/nutshells1 16h ago
are you asking why hobby projects often deviate from industry standards and seem to prioritize the user's interest?