OSDev.org

I don't often post here, I mostly read the wiki and lurk, but I've an idea I'd like to throw out. Recently, I've been working with the Multiboot Specification, and at first glance, it's very useful and complete. However, once I got into it, it seemed to me that several things either are extraneous or not provided for.

First, several things seem outdated, specifically, long mode is not supported in any way. It's actually required that paging be disabled. (U)EFI is similarly disregarded.

Another issue is the lack of requirements on the loader pertaining to memory usage. The only thing I know for sure about a Multiboot compliant loader is that it didn't load anything where my kernel (including BSS area) is. I don't know where it's safe to put things, as the loader's structures don't seem to be represented on the memory map. I believe a reasonable solution to this would be to restrict all loader information that is passed to the kernel from being above 1MB.

Finally, I think there are some fields that the spec doesn't provide, and some that aren't needed. A lot of modular kernels need at least one module loaded at boot time, and this isn't provided in the kernel's header. To be able to load the kernel, the user has to handle some loader-specific method of loading a module with the kernel. For an example of misplaced or unnecessary data, I point to the symbols table. The point of the spec is to allow one loader to load many different types of kernels, regardless of file format. Putting a.out and/or ELF specific data in the spec without doing the same for other formats such as PE seems to imply that the creators were biased toward certain formats, and it makes no sense to make a spec that is designed to be independent of file formats while accommodating one or two of your favorites.

I wanted to share this to get some opinions. Is it just me?

I share your opinion. The multiboot spec is highly targeted to Linux needs, and largely disregards the needs of other environments.

When I made my multiboot interface I actually had to create an imaginary "kernel" (I call it grubload). The real kernel is loaded as a module in memory. The imaginary loader would then contain a loader that complies with my kernel.

The multiboot standard not only does not comply with long-mode, it doesn't comply with segmentation either. It was designed only to support a 32-bit flat memory model based on Linux ELF kernel needs.

Without going into much detail, as this has been discussed over and over again on these forums:

• Multiboot does not disregard (U)EFI, OFW, or other non-BIOS firmware; or long mode. It was just defined a really long time ago. The document is dated last year due to small revisions and recent clarifications.
• The paging bit makes sense because the kernel would need to define its own page tables anyway.
• Multiboot is not Linux-specific. In fact, Linux is not a Multiboot kernel, it has its own protocol.

Multiboot 2 aims to fix the issues that Multiboot has inherited over time and add support for other things such as more different CPU architectures. A few of us on this forum have sent proposals for the new specification but progress is extremely slow. The GRUB maintainer has sent a draft of the Multiboot 2 specification (here is an old version of said draft; you can find the most recent changes in the GRUB repo) to Linux asking them to support it but they simply ignored him

Love4Boobies wrote:

• Multiboot is not Linux-specific. In fact, Linux is not a Multiboot kernel, it has its own protocol.

Multiboot 2 looks like it's making zero progress, and it may not be Linux specific, but it definitely has leanings toward UNIX-type OSs in general, and that has absolutely no place in a spec that's designed to allow portability.

Please elaborate, you are being very vague.

I was referring to the symbols table, which is only applicable to ELF and a.out, while not supporting other formats like PE. Besides, isn't the point to make the loader independent of the file format?

ELF and a.out are not UNIX-specific, although they are indeed used by most UNIX ABIs. You can load other executable formats (such as PE) using a Multiboot kludge, which is the file format independence mechanism you were talking about.

A boot loader should make no assumptions about how the executable file is organized. It should simply load some modules into memory, and then transfer execution to some type of entry-point. For x86-systems, the best would be to pass control while still in real-mode, and let the OS setup its memory model itself. A boot-loader should not make assumptions about the memory-model used by the OS either.

So it is really simple. Take out the ELF/a.out support completely, and pass control to the OS in real-mode for x86-systems.

It should simply load some modules into memory, and then transfer execution to some type of entry-point.

Without using a known format (like ELF or a.out) and making no assumptions about the EXE file format, how would the boot loader know the load addresses ? And the entry point ?

I'm no great fan of Multiboot or Grub, but some standard needs to be created so that progress can be made.

gerryg400 wrote:

It should simply load some modules into memory, and then transfer execution to some type of entry-point.

Without using a known format (like ELF or a.out) and making no assumptions about the EXE file format, how would the boot loader know the load addresses ? And the entry point ?

From the multiboot header, of course.

The simplest solution would be to define a fixed entry-point where the primary boot-image is loaded and then control is transfered much the same way as BIOS does. That would support any type of OS. Any serious OS project eventually need to make it's own boot-loader that works on its own, and providing support for a new variant of real-mode booting is trivial.

From the multiboot header, of course.

But as you know the Multiboot spec supports that and Grub implements it. You simply set bit 16 in the flags field of the Multiboot header.

It seems like you are proposing that functionality be removed from Multiboot. Why is it necessary when those who don't need ELF can switch it off and simply ignore it ?

gerryg400 wrote:

From the multiboot header, of course.

But as you know the Multiboot spec supports that and Grub implements it. You simply set bit 16 in the flags field of the Multiboot header.

It seems like you are proposing that functionality be removed from Multiboot. Why is it necessary when those who don't need ELF can switch it off and simply ignore it ?

Bit 16 in flag field does NOT make grub pass control to the OS-image in real-mode. It still passes control to the OS-image in 32-bit flat mode, and thus I still need an intermediate loader that restarts the boot process.

Any serious OS project eventually need to make it's own boot-loader

Can we make this forum read-only for you so that you quit posting nonsense?

Linux practically never uses its own bootloader for starters. It's all third party software (lilo/grub)

Combuster wrote:

Any serious OS project eventually need to make it's own boot-loader

Can we make this forum read-only for you so that you quit posting nonsense?

Linux practically never uses its own bootloader for starters. It's all third party software (lilo/grub)

I didn't write "need to use". I wrote "need to make". These are completely different issues, and Linux does have it's own boot-loader.

rdos wrote:I didn't write "need to use". I wrote "need to make".

Cool, except it makes even less sense now.

rdos wrote:These are completely different issues, and Linux does have it's own boot-loader.

Spelling isn't the only problem with your argument