[Closed Don't Reply] Old Question

[glauxosdever]

Hi,

I am aware that writing one is a difficult task. I don't think I will be doing another in lets say 10 years from now. It surely takes time, but that is the cost.
Looks like I can't escape GRUB. Thanks for your time.

You can just tolerate using GRUB for a while, until you get to a point where you can see most of the things GRUB doesn't do like you wanted. In fact you already see points of GRUB that are inconvenient for your design. Then...

...When you get to load a 64-bit kernel, you will discover GRUB can't directly load it, and you will have to switch processor modes inside the kernel while pretending it's a 32-bit kernel, or have a pre-kernel module (incorrectly referred to as "kernel" in GRUB parlance) which sets up the environment and passes control to the kernel (incorrectly referred to as "module" in GRUB parlance).

...When you get to ACPI, you will discover that the kernel will have to search/probe the memory for ACPI tables even when booting from UEFI, where the firmware itself provides the relevant addresses (but GRUB doesn't make use of them (in case I am mistaken, the kernel will instead have to detect whether it has been booted from BIOS of UEFI)).

...When you get to make use of available physical memory, you will discover the kernel will have to detect whether it has been booted from BIOS or UEFI in order to interpret the memory map properly. The memory map returned from "int 0x15, eax=0xE820" and the memory map returned from UEFI are incompatible.

Honestly, this is by no means a full list, but rather some things I can think of currently. I'm sure you will sooner or later find more design decisions of GRUB which you will find to be inconvenient. This way you will know almost from the start some design decisions you should not copy in your bootloader. Another option, which should rather be intersected with tolerating GRUB for a while in the beginning, is not to be afraid of modifying the boot specification when you see design mistakes in it. Note: The problem is that the Multiboot specification is used by many operating systems and therefore it's hard to release a new version of it whenever a design mistake is spotted, while the boot specification for your OS can be changed at almost any time since it's used only for your OS.

Video mode switching is not a good reason for rolling your own bootloader - especially if you want to switch video modes at runtime.

He could do it like KolibriOS does it. Have the bootloader display a menu describing graphics modes. As far as I know it's not possible with GRUB.


Regards,
glauxosdever

[iansjack]

6.Many others that I can't remember right away because of how pissed I am, because there is not a single person that can politely explain what I asked

You really know how to persuade people to do you the favour of helping you.

[Octacone]

Hi,

I am aware that writing one is a difficult task. I don't think I will be doing another in lets say 10 years from now. It surely takes time, but that is the cost.
Looks like I can't escape GRUB. Thanks for your time.

You can just tolerate using GRUB for a while, until you get to a point where you can see most of the things GRUB doesn't do like you wanted. In fact you already see points of GRUB that are inconvenient for your design. Then...

...When you get to load a 64-bit kernel, you will discover GRUB can't directly load it, and you will have to switch processor modes inside the kernel while pretending it's a 32-bit kernel, or have a pre-kernel module (incorrectly referred to as "kernel" in GRUB parlance) which sets up the environment and passes control to the kernel (incorrectly referred to as "module" in GRUB parlance).

...When you get to ACPI, you will discover that the kernel will have to search/probe the memory for ACPI tables even when booting from UEFI, where the firmware itself provides the relevant addresses (but GRUB doesn't make use of them (in case I am mistaken, the kernel will instead have to detect whether it has been booted from BIOS of UEFI)).

...When you get to make use of available physical memory, you will discover the kernel will have to detect whether it has been booted from BIOS or UEFI in order to interpret the memory map properly. The memory map returned from "int 0x15, eax=0xE820" and the memory map returned from UEFI are incompatible.

Honestly, this is by no means a full list, but rather some things I can think of currently. I'm sure you will sooner or later find more design decisions of GRUB which you will find to be inconvenient. This way you will know almost from the start some design decisions you should not copy in your bootloader. Another option, which should rather be intersected with tolerating GRUB for a while in the beginning, is not to be afraid of modifying the boot specification when you see design mistakes in it. Note: The problem is that the Multiboot specification is used by many operating systems and therefore it's hard to release a new version of it whenever a design mistake is spotted, while the boot specification for your OS can be changed at almost any time since it's used only for your OS.

Video mode switching is not a good reason for rolling your own bootloader - especially if you want to switch video modes at runtime.

He could do it like KolibriOS does it. Have the bootloader display a menu describing graphics modes. As far as I know it's not possible with GRUB.


Regards,
glauxosdever

I didn't know for half of that stuff.
Thanks man! I don't plan on doing a 64 bit kernel with UEFI any time soon, so that aspect shouldn't be a problem.
Tolerating GRUB is the only thing I can do right now.
That is exactly what I want to do, display a menu describing graphics modes. That is another downside of GRUB (runtime graphics mode switch that I was talking about earlier).
What do you mean by changing multiboot design? You mean recompiling GRUB??

[Octacone]

6.Many others that I can't remember right away because of how pissed I am, because there is not a single person that can politely explain what I asked

You really know how to persuade people to do you the favour of helping you.

Sorry for being a bit nervous.

[Kevin]

That is exactly what I want to do, display a menu describing graphics modes. That is another downside of GRUB (runtime graphics mode switch that I was talking about earlier).

Never used this myself, but I'm pretty sure that you can have a menu for the graphics modes when using GRUB for mode switching. But that's obviously still only before starting the kernel; for switching later on, no bootloader can help you.

[glauxosdever]

Hi,

Thanks man! I don't plan on doing a 64 bit kernel with UEFI any time soon, so that aspect shouldn't be a problem.

As I said, the kernel shouldn't care whether it has been booted by BIOS or UEFI. Unless, do you mean you don't plan on switching to long mode?

Tolerating GRUB is the only thing I can do right now.

Yes, but if you plan on writing your own bootloader, you shouldn't let your kernel have strong relationships with GRUB.

That is exactly what I want to do, display a menu describing graphics modes. That is another downside of GRUB (runtime graphics mode switch that I was talking about earlier).

At runtime, does this mean before the kernel is loaded, or after the kernel is loaded? If you mean the former, you can have your bootloader display a menu during boot. If you mean the latter, then neither GRUB neither your own bootloader have something to do here. Note however that in some decades you will maybe have graphics drivers, so it will be possible (at least for some cards) to switch modes without using VBE.

What do you mean by changing multiboot design? You mean recompiling GRUB??

No. It's something much more complicated than that.

Imagine the GRUB developers decide to modify the multiboot specification. Then, it gets implemented into the next GRUB version. Next, copies of GRUB are installed and now every kernel relying on multiboot breaks, since it tries to parse incompatible information.

Now imagine the GRUB developers decide to release a new version of the multiboot specification, while keeping the old version, let's call it multiboot 3 (multiboot 2 already exists). It gets implemented in the next GRUB version. Newer kernels start implementing multiboot 3. But hey, a design issue in multiboot 3 has been spotted. So the GRUB developers release multiboot 4, which gets implemented in the next GRUB and newer kernels. But hey, something is wrong with multiboot 4, as a result GRUB developers make multiboot 5, etc. This results in bloat in the bootloader (since it has to support multiple multiboot versions), while also multiplied need for documentation (since every multiboot version is different).

When changing the boot specification for your OS, you don't have to support older versions of the boot specification, since both ends (bootloader and kernel) are yours and no other project takes the place of either. So, unlike GRUB developers, you don't have compatibility constraints to fulfill.


Regards,
glauxosdever

[hgoel]

Tolerating GRUB is the only thing I can do right now.

Yes, but if you plan on writing your own bootloader, you shouldn't let your kernel have strong relationships with GRUB.

This.
I suggest defining a structure that contains the boot information in a format your kernel understands, instead of working directly with whatever structures the bootloader provides, then the first step on entering a C environment can be to simply translate the bootloader's structures into your kernel's. That way you aren't bound to any specific boot protocol, switching to another bootloader becomes a matter of writing the routine to translate the bootloader's structures to your kernel's.

[Schol-R-LEA]

Imagine the GRUB developers decide to modify the multiboot specification.

They could no more do that than Microsoft could change the x86 instruction set, because they aren't the ones who make that decision. They have a lot of say in it - most of the GRUB devs are on the Multiboot spec committee - but the Multiboot spec is independent of GRUB; GRUB is the just the reference implementation, not the definition, and it is deliberately limited because they want GRUB to reflect the specification, not the other way around.

There is at least one GRUB fork, called BURG, which is supposed to fix a lot of the issues with GRUB. I also seem to recall at least one of the posters here mentioning a Multiboot-compliant loader that didn't share any GRUB code. I have a long-term plan to implement one myself (Bereshith, which would be the default for Kelephstis and Kether but should work like any other MB boot loader), but that's nowhere on the horizon today.

Also, there are other open-source but non-MB boot loaders around, which have their own models for talking to the kernel. See Wikipedia: Comparison of Boot Loaders and the wiki pages for Gujin and XOSL, among other things.

BTW, are you using GRUB Legacy or GRUB 2? They are quite different.

[CorruptedByCPU]

Hey! Gimme compiled kernel file, I will check with my bootloader.

Your kernel must be compiled with instructions from 0x100000 or relative.

[dchapiesky]

Apache licensed loaders:

https://github.com/01org/ikgt-loader

https://github.com/01org/ikgt-uefi-loader

For the Intel Kernel Guard ring -1 project...

Specify your own payload and go

[glauxosdever]

Hi,

Imagine the GRUB developers decide to modify the multiboot specification.

They could no more do that than Microsoft could change the x86 instruction set, because they aren't the ones who make that decision.

I probably said an inaccuracy then. It was just an example of what would the result be if something like this happened.

My point is that if the committee that maintains the multiboot specification decided to modify it, then the compatibility issues would be spread across many projects (including most of operating systems originated from this community), so it wouldn't really happen. This way multiboot can't include some more useful features, unless a new version is released each time something wrong with the previous version is detected, which doesn't really happen very often either, since more documentation efforts would be needed, along with the inevitable bloat in bootloaders.


Regards,
glauxosdever

[rdos]

I suggest defining a structure that contains the boot information in a format your kernel understands, instead of working directly with whatever structures the bootloader provides, then the first step on entering a C environment can be to simply translate the bootloader's structures into your kernel's. That way you aren't bound to any specific boot protocol, switching to another bootloader becomes a matter of writing the routine to translate the bootloader's structures to your kernel's.

Yes, that's a very important point, especially if your OS evolves over time and you want to be able to upgrade (not reinstall) existing installations. Also, remember that the multi-boot standard is quite different from what you get from EFI, so you need a boot structure that can handle both (+ your own boot-loader).

As for GRUB, I think it is mostly junk. Same thing for the multiboot standard. I have intermediate states both for GRUB and EFI that creates the common data structure and changes to a common processor mode (16-bit protected mode). I also have my own BIOS loader that fills in the data structures by using BIOS calls. The OS image is a bundled binary image of kernel, drivers, files and settings. It's just loaded and then control is transferred to the entry point of the kernel image (which is a 16-bit binary).

So, no, I don't think the boot-loader should setup paging or the operating mode. That's up to the kernel to do. That's what's wrong with both GRUB and EFI. Just think about how almost every EFI-loader today is 64-bit, and thus is unable to start a 32-bit OS directly, simply because it uses the wrong operating mode.

[matt11235]

Just think about how almost every EFI-loader today is 64-bit, and thus is unable to start a 32-bit OS directly, simply because it uses the wrong operating mode.

You could argue that if you're writing a 32-bit OS, you're writing it in the wrong operating mode

[rdos]

Just think about how almost every EFI-loader today is 64-bit, and thus is unable to start a 32-bit OS directly, simply because it uses the wrong operating mode.

You could argue that if you're writing a 32-bit OS, you're writing it in the wrong operating mode

Actually, I support both operating modes, but I always start from protected mode.

[Brendan]

Hi,

Just think about how almost every EFI-loader today is 64-bit, and thus is unable to start a 32-bit OS directly, simply because it uses the wrong operating mode.

You could argue that if you're writing a 32-bit OS, you're writing it in the wrong operating mode

Actually, I support both operating modes, but I always start from protected mode.

I have a "Boot Abstraction Layer" (BAL) that always runs in 32-bit protected mode (where the boot loader provides an abstract API for BAL to use). For BIOS boot loaders this means a wrapper that switches between real mode and protected mode. For 64-bit UEFI boot loaders this means a wrapper that switches between long mode and protected mode. After the BAL has finished with the boot loader it detects CPUs and starts them and determines the features that all CPUs support (e.g. in case the BSP supports long mode but an AP doesn't), and decides if it should start a 32-bit kernel or a 64-bit kernel (and there are "boot variables" that can be used to force BAL to choose to start a 32-bit kernel on 64-bit systems).

The end result of this is that you can start a 32-bit kernel from 64-bit UEFI, or start a 64-bit kernel from 32-bit UEFI, or start either type of kernel from BIOS. It makes no difference.


Cheers,

Brendan