OSDev.org

Hi there! So I started tinkering with osdev a little while ago and it is one of those things that fascinated me. I decided to loosely follow a couple tutorials to learn a bit more and ended up, more or less with a similar result to https://github.com/cfenollosa/os-tutorial. I was looking into different project structures (specifically the meaty skeleton one here on the wiki) to expand my OS into something usable and easy to add to, however I quickly found myself overwhelmed with the sheer amount of different source code structures and build formats as well as most examples (I have come across) using grub as a bootloader. My main question is, what is the best way I can structure my OS if I want to roll my own bootloader?

I am sorry if this question seems kind of dumb with all of the information out there but with osdev being so open ended and without only one way to do it, I am at a loss for what I should do next so if someone could at least point me in the right direction, that would be great.

Bootloader development has very little to do with OS development. Are you really sure you want to write your own bootloader?

The structure of your OS doesn't depend on the bootloader unless you're planning something exotic. Perhaps the biggest difference is that your own bootloader can do things that GRUB can't, like switching to long mode.

This is a slippery and loooooog slope, might want to consider clearly define non-goals first.

For example 'replacing grub' is a non-goal for me as I've always been amazed by its capability, and convenience.

IMHO it is more like a real OS than many 'OS projects' out there. As you might know, grub has a shell that can display files in partitions that have filesystems ranging from ZFS to EXT4, with FUSE support on top of all that. I doubt more than a tiny percentage of 'hobby OSes' can do this.

Also, any bit of convenience felt by the user for a piece of program at such a low level and early stage likely amounts to great deal of incontinence for the developer.



This is a super hard problem since it isn't about how to put source files into folders, but more about how to design the whole architecture. All the modules, interfaces and the general hierarchy that puts all of them into the right places.

I'm not qualified to answer this in this context, but the typically right way to start is to spend a long time writing design documents, and be prepared that way more than a long time will be spent on deleting (as the needed changes can be so extensive there's little to salvage from the previous revisions) and re-writing the design documents down the road. This is all before the first line of code should be written.

Or don't be so serious with a hobby and have some fun while learning what you can, just take the https://wiki.osdev.org/Cowboy_Coder route and pick whatever you are interested and start coding.



This is "easy", does the thing take more than a coffee break's time to build so you are annoyed? If not just use whatever lousy build system/method that builds the thing for now unless your aspiration is build engineering.

There is no "best way". It's all a matter of personal choice.

But I strongly agree with others that it is more interesting to get on with developing the OS itself rather than re-inventing the bootloader. Is there something special that you want it to do that GRUB doesn't provide?

As others have said, it depends what kind of OS you want. To look at this from a bit of a higher perspective, do you want to make a POSIX-compatible OS? This will make it easy to port a lot of software to your OS, but restricts your choices and makes your OS similar to hundreds of other OSs. (You may find the deeper differences between POSIX implementations interesting anyway.) If you don't, then you have more choices. What sort of IO interfaces do you want? Unix-like synchronous files or async i/o? Both? That's pretty fundamental. What about message passing? If it uses the same interfaces as IO, it will add flexibility to your system and might save you some work. How will service discovery work? That's less important, it could be omitted for a toy, retro, or perhaps embedded OS. I didn't consider the scheduler, if you even want a multitasking OS.

I thought there was a wiki page covering this in more detail, but I can't find it now.

Hi,

I wanted to address the original question on source code structure with respect to custom boot loaders by sharing what we do. I would like to emphasize however that there is no one single structure; this is designed this way for reasons that is specific to our goals and ideas. In fact, before deciding on a structure, you should decide on your build system and how you plan to automate the building of the image file (microkernel vs monolithic, auto-build out of date dependencies, architecture or firmware specific code, etc.) The system you use will have an effect on how you structure and plan the code base. The basic idea is that the boot library defines a set of device objects and drivers and provides runtime support for the main boot loader program. To build with EFI, just link with the EFI boot library. To build with BIOS, link with the BIOS boot library and prepend nstart to the file. The firmware-specific library defines a common set of driver objects that the run time or program calls indirectly. The loader has very little effect on code structure -- except perhaps how you handle architecture specific code and firmware specific code with respect to the build system. We put architecture specific code in folders and there is one boot library for EFI and another for BIOS in "nbl" and other libraries for boot drivers and runtime support. The makefile system allows us to do something like "nbuild ARCH=x86 FW=BIOS" to target it.

Just have fun and work on what you are interested in. You will probably even see yourself changing the structure and basic designs a lot early on as the system gets more larger. Study existing operating systems and experiment with what interests you. My first boot loaders long ago were in assembly language, then I experimented with writing them in C and adopted it from there. This is what it should be about: experimenting and researching: if you want to try something, go for it. You should know though that writing good boot loaders can take a really long time as they can become as complex as small operating systems themselves -- so only do so if you are wanting it -- you don't have to, after all.

If this is the first time into OS development without guides or tutorials though, it can be a good idea to stick with something existing for now. If you have good need or are more confident later on you can always replace the loader (if you stick with something like GrUB for now, in theory it can be replaced with any multi-boot compliant loader.)

I think that is a good time to buy a book about OS design, for example "Operating system design and implementation" by Tanenbaum.
And I think it is cool to develop your own bootloader, but that means you are kind of standing still, you don't move on to more advanced and exciting stuff.
(You didn't name your target architecture, so I guess it is x86 protected mode with legacy BIOS.)

Greetings
Peter