grub-devel
[Top][All Lists]
Advanced

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

Re: some multiboot2 comments


From: Hollis Blanchard
Subject: Re: some multiboot2 comments
Date: Fri, 27 Oct 2006 00:37:35 -0500

On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
> On Thu, Oct 26, 2006 at 02:58:35PM -0500, Hollis Blanchard wrote:
> > http://grub.enbug.org/MultibootDraft
> > 
> > I'm looking at implementing this now.
> > 
> > Module:
> > Because of the 'length' field in the tag header, the 'reserved' field
> > isn't actually needed. The 'length' field makes every one of these tag
> > structures inherently variably sized. Any data added later to this tag
> > will be skipped over by the reader.
> Yes.
> BTW, why not adding a type field for module tag.  The type (which should be
> an UUID IMHO) should indicate the type of the module.
> One usage could be for Xen.  On Xen you can load 3 modules: the linux kernel,
> the linux ramdisk and an ACM configuration.  Xen relies on order and on some
> magic checks to find the module type.
> The command syntax could be:
> module [-type TYPE] file [cmdline]

What do you mean by UUID? I certainly would not like to see large magic
numbers required in grub.cfg...

> > Memory Map:
> > I'm not sure if we need this. The OS can get this information from
> > firmware (e.g. BIOS e820 map or Open Firmware) as easily as we can,
> > right? In general, I don't think we should convert firmware information
> > into the multiboot structure.
> Some platform may need it. On EFI the OS can't get the memmap from EFI because
> it is too late.

OK. In that case we're still keeping with the philosophy of only passing
information to the kernel that it can't obtain itself.

-Hollis





reply via email to

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