From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gspfy-0003BN-JS for mharc-grub-devel@gnu.org; Fri, 08 Dec 2006 19:02:46 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gspfx-0003BA-HH for grub-devel@gnu.org; Fri, 08 Dec 2006 19:02:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gspfu-0003AE-4g for grub-devel@gnu.org; Fri, 08 Dec 2006 19:02:44 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gspft-0003A0-Qg for grub-devel@gnu.org; Fri, 08 Dec 2006 19:02:41 -0500 Received: from [32.97.182.142] (helo=e2.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 1Gspft-0001kj-7k for grub-devel@gnu.org; Fri, 08 Dec 2006 19:02:41 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kB902cT0020531 for ; Fri, 8 Dec 2006 19:02:38 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB902ZTn306648 for ; Fri, 8 Dec 2006 19:02:38 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB902ZDf015645 for ; Fri, 8 Dec 2006 19:02:35 -0500 Received: from [9.53.41.42] (basalt.austin.ibm.com [9.53.41.42]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB902ZUx015639 for ; Fri, 8 Dec 2006 19:02:35 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <20061027040907.GA2485@saphi> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061027040907.GA2485@saphi> Content-Type: text/plain Date: Fri, 08 Dec 2006 18:02:31 -0600 Message-Id: <1165622551.23364.66.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: Sat, 09 Dec 2006 00:02:45 -0000 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?) 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. 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; -Hollis