From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gecc4-000665-JB for mharc-grub-devel@gnu.org; Mon, 30 Oct 2006 14:16:00 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gecc2-00065d-RC for grub-devel@gnu.org; Mon, 30 Oct 2006 14:15:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gecbx-00061N-21 for grub-devel@gnu.org; Mon, 30 Oct 2006 14:15:57 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gecbw-00061J-Oi for grub-devel@gnu.org; Mon, 30 Oct 2006 14:15:52 -0500 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gecbw-00019d-Aq for grub-devel@gnu.org; Mon, 30 Oct 2006 14:15:52 -0500 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id 7E28E3CC7F4E4 for ; Mon, 30 Oct 2006 22:54:20 +0100 (CET) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 5723A3CC7F4DF for ; Mon, 30 Oct 2006 22:54:20 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Mon, 30 Oct 2006 21:15:45 +0200 User-Agent: KMail/1.8.2 References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <200610281611.01094.okuji@enbug.org> <1162060334.7640.8.camel@diesel> In-Reply-To: <1162060334.7640.8.camel@diesel> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610302015.45634.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.484634, version=0.17.2 Subject: Re: some multiboot2 comments 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: Mon, 30 Oct 2006 19:15:59 -0000 On Saturday 28 October 2006 20:32, Hollis Blanchard wrote: > Are you saying that given tag->key == foo, tag->length == sizeof(struct > tag_foo)? I think it makes far more sense to allow 'length' to be > independent of 'key', and that means we don't need this 'reserved' > stuff. 'length' is sometimes somehow independent. When passing data whose size is variable, 'length' specifies the size. The size of an item is indirectly defined by 'length'. The size of an item can be different from the size of data, because of a padding for an alignment. Okuji