From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gdsyl-0006U8-40 for mharc-grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:23 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gdsyi-0006Pk-5B for grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gdsyg-0006MG-7k for grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gdsyf-0006LY-Pg for grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:17 -0400 Received: from [207.69.195.63] (helo=pop-satin.atl.sa.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gdsyf-0000If-Ph for grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:17 -0400 Received: from user-0vvdf2d.cable.mindspring.com ([63.246.188.77] helo=diesel.unsanctioned.org) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1Gdsyd-0006wC-00 for grub-devel@gnu.org; Sat, 28 Oct 2006 14:32:15 -0400 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <200610281611.01094.okuji@enbug.org> References: <1161892715.17811.33.camel@basalt.austin.ibm.com> <200610281611.01094.okuji@enbug.org> Content-Type: text/plain Date: Sat, 28 Oct 2006 13:32:14 -0500 Message-Id: <1162060334.7640.8.camel@diesel> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit 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: Sat, 28 Oct 2006 18:32:20 -0000 On Sat, 2006-10-28 at 16:11 +0200, Yoshinori K. Okuji wrote: > On Thursday 26 October 2006 21:58, Hollis Blanchard wrote: > > Module: > > Because of the 'length' field in the tag header, the 'reserved' field > > isn't actually needed. The 'length' field makes every one of these tag > > structures inherently variably sized. Any data added later to this tag > > will be skipped over by the reader. > > Only if you can specify tag size separately. In the current draft, the size of > a tag is defined by "length" which describes the real size of the content. So > if we don't include "reserved", there is no additional space for the future, > except for a possible padding. 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. If 'length' is always sizeof(something), then we might as well drop 'length' entirely, and I don't think that would be a good idea. -Hollis