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