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: Hollis Blanchard
Subject: Re: multiboot2: make multiboot header optional
Date: Wed, 15 Nov 2006 12:42:25 -0600

On Wed, 2006-11-15 at 09:57 +0100, Johan Rydberg wrote:
> Hollis Blanchard <address@hidden> writes:
> 
> > For kernels that need to communicate information to GRUB (e.g.
> > "vga_mode" from my previous email, or a.out load addresses), the
> > multiboot header would be needed for GRUB to locate the parameter area
> > within the executable.
> 
> My two cents;
> 
> In MB2 we remove the possibility to communicate options from the
> kernel to the boot loader.  The loader has one task; loading the
> kernel and leave control to it, and possible pass information about
> the environment.  Nothing more.
> 
> 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.

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.

If we do require format-specific loaders, the multiboot2 loader could
just be renamed to "elf", leaving the legacy i386 multiboot loader
intact.

To support straight binary kernels with a "binary" loader, the kernel
could be loaded at e.g. 0x7c00 (on x86) and passed the multiboot tags.

-Hollis





reply via email to

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