From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GuGWN-0003CI-K5 for mharc-grub-devel@gnu.org; Tue, 12 Dec 2006 17:54:47 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuGWL-0003AP-LP for grub-devel@gnu.org; Tue, 12 Dec 2006 17:54:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuGWK-000395-P7 for grub-devel@gnu.org; Tue, 12 Dec 2006 17:54:44 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuGWK-00038l-AQ for grub-devel@gnu.org; Tue, 12 Dec 2006 17:54:44 -0500 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuGWJ-0006GM-Vm for grub-devel@gnu.org; Tue, 12 Dec 2006 17:54:44 -0500 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id 308CE3CD0BB6D for ; Wed, 13 Dec 2006 02:51:54 +0100 (CET) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 043C73CD0BB68 for ; Wed, 13 Dec 2006 02:51:54 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 12 Dec 2006 23:54:41 +0100 User-Agent: KMail/1.8.2 References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061209053133.GA2526@saphi> <1165956970.28426.21.camel@basalt> In-Reply-To: <1165956970.28426.21.camel@basalt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612122354.41559.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.392530, version=0.17.2 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 22:54:46 -0000 On Tuesday 12 December 2006 21:56, Hollis Blanchard wrote: > 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 am for making "type"s arbitrary. If one wants to use a "type" as an UUID, she can. If one wants to use a "type" as a symbolic name, she can. I think it is the most flexible and simplest way to make the interpretation of "type"s up to the user. Okuji