From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GuEhb-00030R-0j for mharc-grub-devel@gnu.org; Tue, 12 Dec 2006 15:58:15 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuEhZ-0002zn-H3 for grub-devel@gnu.org; Tue, 12 Dec 2006 15:58:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuEhX-0002z4-Qz for grub-devel@gnu.org; Tue, 12 Dec 2006 15:58:13 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuEhX-0002z1-Kb for grub-devel@gnu.org; Tue, 12 Dec 2006 15:58:11 -0500 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GuEhX-0004lx-OO for grub-devel@gnu.org; Tue, 12 Dec 2006 15:58:11 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kBCKw25v027530 for ; Tue, 12 Dec 2006 15:58:02 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBCKuNCA142870 for ; Tue, 12 Dec 2006 15:56:24 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBCKuMbv019610 for ; Tue, 12 Dec 2006 15:56:23 -0500 Received: from [9.53.41.42] (basalt.austin.ibm.com [9.53.41.42]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBCKuMn4019584 for ; Tue, 12 Dec 2006 15:56:22 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <20061209053133.GA2526@saphi> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061027040907.GA2485@saphi> <1165622551.23364.66.camel@basalt> <20061209053133.GA2526@saphi> Content-Type: text/plain Date: Tue, 12 Dec 2006 14:56:10 -0600 Message-Id: <1165956970.28426.21.camel@basalt> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: identifying module types X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 20:58:13 -0000 On Sat, 2006-12-09 at 06:31 +0100, Tristan Gingold wrote: > On Fri, Dec 08, 2006 at 06:02:31PM -0600, Hollis Blanchard wrote: > > On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote: > > > 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] > > > > As I'm implementing the Xen side of this, I can now see the need. > > > > Xen uses a handful of modules: > > - xen kernel > > - dom0 kernel > > - dom0 initrd > > - security policy (binary blob) > > - possibly others > > > > On the consumer side of multiboot (in this case Xen), we need to loop > > over the tags, and when we find a module tag, how do we know which it > > is? The Multiboot2 spec tells us "The order of modules is not > > guaranteed." (Why not?) > Currently Xen relies on the order. Maybe the spec should be slighly changed? > > > If we can't rely on the order, then we have no reliable way to > > distinguish the type of module we're looking at, so a type field would > > be extremely useful. For example: > > multiboot (hd1,1)/xen > > module -t xenhv-dom0 (hd1,1)/vmlinux > > module -t xenhv-dom0-initrd (hd1,1)/initrd > > or > > multiboot (hd0,0)/boot/gnumach.gz root=device:hd2s1 > > module -t hurd-something (hd0,0)/lib/ld.so.1 > > > > One option is a fixed-length encoded field, say 32 bytes wide. To avoid > > namespace collisions, we could require that projects prefix types with > > their project name, which must be at least 4 bytes. > Nb: UUID are 16 bytes and collisions are avoided. Please detail your proposal. > I prefer the use of a fixed-length field. Me too. > But that's my own opinion (UUID are > easy to generate, to compare and well-known - do not reinvent the wheel). UUIDs, e.g. 550e8400-e29b-41d4-a716-446655440000, are also completely unintelligible, so they cannot be the only answer. So far you seem to be advocating the following: module [--type TYPE | --uuid UUID] file TYPE: an English word that GRUB translates to a UUID. GRUB must therefor maintain a table of known types and their associated UUIDs. UUID: a 16-byte number which can be represented as 36 ASCII characters (including hyphens). How should we generate the UUIDs for the table in GRUB? I'll just run uuidgen here and create them myself? Does anybody object to this scheme? -Hollis