From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gsv61-0003rC-44 for mharc-grub-devel@gnu.org; Sat, 09 Dec 2006 00:50:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gsv5x-0003oM-QZ for grub-devel@gnu.org; Sat, 09 Dec 2006 00:49:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gsv5s-0003lO-EP for grub-devel@gnu.org; Sat, 09 Dec 2006 00:49:54 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gsv5r-0003lC-IN for grub-devel@gnu.org; Sat, 09 Dec 2006 00:49:51 -0500 Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gsv5r-0002Qi-3M for grub-devel@gnu.org; Sat, 09 Dec 2006 00:49:51 -0500 Received: from saphi (boi78-1-82-232-198-173.fbx.proxad.net [82.232.198.173]) by smtp4-g19.free.fr (Postfix) with ESMTP id 5D3088899 for ; Sat, 9 Dec 2006 06:49:49 +0100 (CET) Received: from gingold by saphi with local (Exim 3.36 #1 (Debian)) id 1GsuoA-0000hJ-00 for ; Sat, 09 Dec 2006 06:31:34 +0100 Date: Sat, 9 Dec 2006 06:31:33 +0100 To: The development of GRUB 2 Message-ID: <20061209053133.GA2526@saphi> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061027040907.GA2485@saphi> <1165622551.23364.66.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1165622551.23364.66.camel@basalt> User-Agent: Mutt/1.5.9i From: Tristan Gingold 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: Sat, 09 Dec 2006 05:49:58 -0000 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. > Another alternative would be a NULL-terminated string, which would > appear in memory just before the NULL-terminated command line, e.g. > x e n \0 c o n s o l e = c o m 2 \0 > This is more flexible, but slightly more awkward on the consumer side: > type = module_tag->text; > cmdline = strchr(module_tag->text, '\0') + 1; I prefer the use of a fixed-length field. But that's my own opinion (UUID are easy to generate, to compare and well-known - do not reinvent the wheel). Tristan.