Bootloaders/MBR and GRUB

[LadyTemoshi]

So I started reading up on Bootloaders, and before I get into more information, I hear suggestions that I should start with GRUB? Even though I'm starting on an OS from scratch for the first time, I should be using an existing bootloader?

I would rather design my own since my OS will be used for other purposes, and not like how Linux is used. I will be using a separate HDD for testing purposes.

I had advice from a programmer friend that creating a bootloader should be my first step.

[iansjack]

There's nothing to stop you writing your own bootloader, but there's no real need to. A bootloader does a very specific job, quite separate from the rest of an OS, and many good ones already exist.

I'm surprised that a programmer suggests this as a necessary first step; they are normally all in favour of using existing, tested components. Does (s)he write operating systems or are they a general purpose program programmer?

[LadyTemoshi]

They understand assembly, and have created their own os... I was reading into bootloaders after he suggested it, so that's why I thought I'd ask here.

I might consider a bootloader later, if it's needed. By the looks of this guide, it didn't seem necessary, and I'd thought I'd ask here.

[Craze Frog]

Writing a bootloader is a waste of time unless you specifically enjoy doing it. If you want to write an OS, start with the kernel, which is an object file (plain binary or elf) loaded by the bootloader.

[Brendan]

Hi,

So I started reading up on Bootloaders, and before I get into more information, I hear suggestions that I should start with GRUB? Even though I'm starting on an OS from scratch for the first time, I should be using an existing bootloader?

The important thing is not the boot loader. The important thing is the standard that determines the interaction between the boot loader and the OS (e.g. what the boot loader loads, where it loads it, what information it gathers, how that information is passed to the OS, etc). For example, an OS that uses multi-boot can switch from any boot loader that supports multi-boot to any other boot loader that supports multi-boot with almost no work/hassle at all; but to switch from (e.g.) multi-boot to "Linux boot protocol" does take work even if the boot loader you happen to be using supports both standards and you don't change boot loader at all.

I'd suggest:

• Write a simple boot loader yourself, then
• Switch to a generic standard like multi-boot, then
• Re-assess the standard you're using, and if/when the standard you're using is restricting the design of your OS consider designing your own standard (and implementing boot loaders that comply with your standard)

The reason for writing a simple boot loader yourself is that it gives you some idea of how they're implemented and the sorts of compromises made during the design of boot loaders. More importantly, it gives you a little practice designing a standard that determines the interaction between the boot loader and the OS and helps you start thinking about what you actually want.

The reason for switching to a generic boot loader is that it takes a while for an OS developer to gain experience with their own OS's design, and this experience is needed before they can figure out what their OS wants from a standard that determines the interaction between the boot loader and the OS.

The reason for re-assessing the standard you're using is that you can't really make an informed decision until after you've enough experience to determine your OS's requirements.

Note: people who skip the first phase are less likely to start thinking about what they actually want; and people that don't think about what they actually want are less likely to do anything interesting and reach the "generic standard is restricting the design of the OS" phase.

I would rather design my own since my OS will be used for other purposes, and not like how Linux is used. I will be using a separate HDD for testing purposes.

If you want to skip the first 2 phases and go directly to the "generic standard is restricting the design of your OS" phase; then you should be able to write a list of these restrictions. I don't think you can do that yet; therefore I recommend that you write your own boot loader (first phase) instead of writing your own boot loaders (third phase)..


Cheers,

Brendan

[justin]

I agree 100% with Brendan. I wrote an operating system for two main reasons: to do something fun and to learn how a computer works. So for me, skipping writing my own bootloader would have left a huge gap in my knowledge of the whole process. I began writing my own and am just now switching over to GRUB now that I have an appreciation of what is involved.

Writing your own bootloader also gives you a sense of the freedom that you have in implementing your OS. You do not need to be constrained to any particular standard as long as you successfully transfer control to your kernel.

In the end, it really depends on what your goals are. Do you want the satisfaction of having a thorough understanding of the entire process or are you OK with using a "black box" for the bootloader and focusing only on kernel development?

[Antti]

I'm surprised that a programmer suggests this as a necessary first step; they are normally all in favour of using existing, tested components.

There are also tested kernels available. I would also suggest writing own boot loader first. I agree with Brendan and justin. Experienced users often have difficulties to understand that new OS developers do not know as much as they do. Even though it is reasonable to use a well-tested boot loader (e.g. GRUB) if your own boot loader does not bring anything new to booting process, it is a decision to be made after you are experienced enough to understand why it would be a better choice. Leaving this huge black box unopened because "it is not a part of an OS" would very likely cause problems in the future.

Besides, I think the "flat" boot loader development gives much more "low-level" feel when starting things. I mean: build a flat image written in assembler. Then the tool-chain "overhead" is minimal and does not gain too much attention at the beginning. Another option is to start building "a kernel" (is it really a kernel at the beginning?) directly with a GCC cross-compiler setup, using ELF and GRUB. I think it would suddenly turn out far too high-level. Are you sure you are in charge anymore in this case because the biggest part of the whole thing would be to concentrate on making the tool-chain work and study standards/conventions made by others rather than just writing low-level code and be innovative? It is possible to be a generic Unix-like-OS developer later if innovations do not succeed. Tongue-in-cheek.