Re: multiboot2: make multiboot header optional

[Hollis Blanchard]

On Wed, 2006-11-15 at 22:42 +0200, Yoshinori K. Okuji wrote:
> On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
> > > If the operating system kernel is stupid enough to require as special
> > > video mode the user should be aware of that and setup the bootloader
> > > so that it is in that mode before the kernel is started.
> >
> > The only information in the multiboot header is a) the load addresses
> > for a.out and "other" formats, and b) the VGA info.
> >
> > We could certainly drop the VGA info.
> 
> No. The problem is that a kernel cannot initialize VESA in protected mode in 
> some BIOSes. If you need more info, please dig into the archive of bug-grub.

OK, that is unfortunate.

> > I don't think it would be a big deal to drop a.out as well; I don't know
> > of any modern OS that uses these, and anyways kernel builds are special.
> > However (and I don't know how reasonable this is), Mac OS X's toolchain
> > will build only Mach-O binaries, so one would be unable to build a
> > kernel that GRUB could load. We could require a Mach-O loader in that
> > case, but I will admit that the "a.out hack" multiboot header fields
> > simplify this problem.
> 
> Never drop the a.out kludge. This flexibility is one of the advantages in 
> Multiboot. Note that GRUB itself uses this feature.

I still would like an improvement in the kernel->GRUB communication.
What about reusing the tags structure? For example:

multiboot_header:
        .long MAGIC
        .long MULTIBOOT_TAG_START [...]
        .long MULTIBOOT_TAG_LOADADDR ; .long 12 ; .long _start
        .long MULTIBOOT_TAG_ENTRYADDR ; .long 12 ; .long main
        .long MULTIBOOT_TAG_END ; .long 8
etc?

A cpp macro or two could make that a little more convenient.

The fact that the START tag requires the number of tags and number of
bytes is inconvenient here. Do we really need that? Why not just:

        while (tag->key != MULTIBOOT_TAG_END)
                process_tag(tag);

-Hollis