grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiboot2: make multiboot header optional


From: tgingold
Subject: Re: multiboot2: make multiboot header optional
Date: Thu, 16 Nov 2006 00:38:55 +0100
User-agent: Internet Messaging Program (IMP) 3.2.5

Quoting Hollis Blanchard <address@hidden>:

> On Wed, 2006-11-15 at 22:42 +0200, Yoshinori K. Okuji wrote:
> > On Wednesday 15 November 2006 19:42, Hollis Blanchard wrote:
[...]
> > > 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);
I really like such tags structure.
Tags structure are *very* flexible: can be easily extended without breaking
backward compatibility.

Tristan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]