From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GuHfK-0005Jz-Mw for mharc-grub-devel@gnu.org; Tue, 12 Dec 2006 19:08:06 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuHfH-0005IP-Jk for grub-devel@gnu.org; Tue, 12 Dec 2006 19:08:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuHfE-0005HS-Pk for grub-devel@gnu.org; Tue, 12 Dec 2006 19:08:03 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuHfE-0005HH-IN for grub-devel@gnu.org; Tue, 12 Dec 2006 19:08:00 -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 1GuHfE-0007Sv-Ai for grub-devel@gnu.org; Tue, 12 Dec 2006 19:08:00 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kBD07vNZ010644 for ; Tue, 12 Dec 2006 19:07:57 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBD07dx4207660 for ; Tue, 12 Dec 2006 19:07:57 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBD07dsg004210 for ; Tue, 12 Dec 2006 19:07:39 -0500 Received: from [9.53.41.42] (basalt.austin.ibm.com [9.53.41.42]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBD07dtb004197 for ; Tue, 12 Dec 2006 19:07:39 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <200612122328.16322.okuji@enbug.org> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <20061027040907.GA2485@saphi> <1165622551.23364.66.camel@basalt> <200612122328.16322.okuji@enbug.org> Content-Type: text/plain Date: Tue, 12 Dec 2006 18:07:26 -0600 Message-Id: <1165968446.28426.81.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: Wed, 13 Dec 2006 00:08:03 -0000 On Tue, 2006-12-12 at 23:28 +0100, Yoshinori K. Okuji wrote: > On Saturday 09 December 2006 01:02, Hollis Blanchard wrote: > > 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?) > > Because the spec does not know how modules are loaded by a boot loader at all. > It does not know how to configure a boot loader. It does not know whether it > is possible to interact with a boot loader at runtime. On the assumption in > the spec, all we can say is that it is recommended that modules are loaded in > the order specified by the user, if possible. We may not say "must" here. I guess I'm not clear on this. The modules must be enumerated in some order, whether manually by the user or in a config file or by a script. Wouldn't it be appropriate to require that this order be preserved? Are you envisioning a scenario like a collection of "module" files in a menuentry.d directory, and then what is the order? Xen could go on depending on the ordering, with the caveat that bootloaders which reorder modules won't work. > > 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; > > Isn't it easier to pass two strings rather than packing them to a single > string? > > type = module->type; > cmdline = module->cmdline; That only works if module->type is of fixed size. What size would you like? Aside from the arbitrary user-visible limit, a fixed size may make namespace collisions more likely (though certainly we would need to account for collisions even if the size were variable). -Hollis