From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gdots-00012z-IA for mharc-grub-devel@gnu.org; Sat, 28 Oct 2006 10:11:04 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gdotq-00010Q-W2 for grub-devel@gnu.org; Sat, 28 Oct 2006 10:11:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gdotp-0000ym-Ud for grub-devel@gnu.org; Sat, 28 Oct 2006 10:11:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gdotp-0000yj-PM for grub-devel@gnu.org; Sat, 28 Oct 2006 10:11:01 -0400 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gdotp-0004te-1G for grub-devel@gnu.org; Sat, 28 Oct 2006 10:11:01 -0400 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id 1CE9E3CC7F4D4 for ; Sat, 28 Oct 2006 18:48:35 +0200 (CEST) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id F3A033CC7F4D3 for ; Sat, 28 Oct 2006 18:48:34 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 28 Oct 2006 16:11:00 +0200 User-Agent: KMail/1.8.2 References: <1161892715.17811.33.camel@basalt.austin.ibm.com> In-Reply-To: <1161892715.17811.33.camel@basalt.austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610281611.01094.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.499966, 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: Sat, 28 Oct 2006 14:11:03 -0000 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. Okuji