Ideas about Mutiboot Specification
Random notes about the next version of Multiboot Specification.
Redesign or not
There are some discussions about redesigning the Multiboot Specification. Here are some reasons:
- The current spec is not easy to extend, because it uses a fixed table.
- It is not to easy to implement, because the table has pointers to external memory regions.
- Bit-fields are not flexible.
- It is not easy to interpret, because the information can be put in random places in theory. This makes the initialization of an OS image very hard.
On the other hand, if it is changed dramatically, it loses compatibility, so it won't work with existing implementations. This forces OS developers to rewrite their boot code.
One sexy proposal about the redesign is to use tagged format. This uses a list of elements, where each element has a tag name (a kind of code or id), its own length, and the contents (value).
+------+------+-------+------ +------+------+-------+ | Tag0 | Len0 | Data0 | Tag1 .... | TagN | LenN | DataN | +------+------+-------+------ +------+------+-------+
The advantages in this format are:
- The structure is dynamic. You do not have to care about fixed offsets.
- It is easy to add new tags, so very extensible.
- It is easy to define arch-specific tags.
- All information is guaranteed to be compacted into one region.
I (okuji) like this idea very much. This is elegant, beautiful and clean. But I don't know if this should be applied to Multiboot Header as well.
2 cents
Tag-Length-Value could indeed be easier to follow, even if the actual structure of the multiboot infos wouldn't be that bad to follow if they were guaranteed to fit a contiguous amount of memory (that the loaded kernel can easily relocate if needed) -- PypeClicker
Compatibility with the actual multiboot header is (imho) highly important. The extended info in T-L-B fashion could be pointed by the multiboot info structure, but i'd be scared of a replacement -- PypeClicker
the multiboot info as given by GrubLegacy is lacking info about the PCI configuration mode supported by the BIOS. That would be a nice thing to have ...