[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some multiboot2 comments
From: |
Tristan Gingold |
Subject: |
Re: some multiboot2 comments |
Date: |
Sun, 29 Oct 2006 17:38:23 +0100 |
User-agent: |
Mutt/1.5.6+20040907i |
On Fri, Oct 27, 2006 at 12:37:35AM -0500, Hollis Blanchard wrote:
> 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...
grub should be aware of the main module types. For these TYPE is a keyword
such as ramdisk, kernel, xen-acm...
For not yet known types, TYPE can be an UUID.
UUID doesn't require a central administration. I think this is a real
advantage.
> > > 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.
Yes.
Tristan.
Re: some multiboot2 comments, Yoshinori K. Okuji, 2006/10/28