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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
