From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gub14-0005px-Ac for mharc-grub-devel@gnu.org; Wed, 13 Dec 2006 15:47:50 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gub11-0005mF-AT for grub-devel@gnu.org; Wed, 13 Dec 2006 15:47:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gub10-0005km-82 for grub-devel@gnu.org; Wed, 13 Dec 2006 15:47:46 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gub10-0005kd-3i for grub-devel@gnu.org; Wed, 13 Dec 2006 15:47:46 -0500 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gub0z-0008Kb-RG for grub-devel@gnu.org; Wed, 13 Dec 2006 15:47:46 -0500 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id A36393CD0BB38 for ; Thu, 14 Dec 2006 00:45:19 +0100 (CET) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 60C753CD0BB34 for ; Thu, 14 Dec 2006 00:45:19 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Wed, 13 Dec 2006 21:47:43 +0100 User-Agent: KMail/1.8.2 References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <200612122328.16322.okuji@enbug.org> <1165968446.28426.81.camel@basalt> In-Reply-To: <1165968446.28426.81.camel@basalt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612132147.43344.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.003043, 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: Wed, 13 Dec 2006 20:47:47 -0000 On Wednesday 13 December 2006 01:07, Hollis Blanchard wrote: > 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? The problem is that there is no universal way to specify what an "order specified by the user" means. If the spec defines that it is a must, the spec must specify how a boot loader accepts user input, etc. > Are you envisioning a scenario like a collection of "module" files in a > menuentry.d directory, and then what is the order? Not really, but I think this is a good point. > Xen could go on depending on the ordering, with the caveat that > bootloaders which reorder modules won't work. I agree. > That only works if module->type is of fixed size. What size would you > like? Ah, I got it. So it is necessary to terminate a type with a NUL value and pack it into a tag. > 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). Right. Okuji