From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GuFni-0001cl-44 for mharc-grub-devel@gnu.org; Tue, 12 Dec 2006 17:08:38 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GuFnf-0001bO-Re for grub-devel@gnu.org; Tue, 12 Dec 2006 17:08:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GuFna-0001Xt-Db for grub-devel@gnu.org; Tue, 12 Dec 2006 17:08:35 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GuFna-0001Xc-57 for grub-devel@gnu.org; Tue, 12 Dec 2006 17:08:30 -0500 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GuFnZ-0004i3-NE for grub-devel@gnu.org; Tue, 12 Dec 2006 17:08:29 -0500 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id 6535A3CD0BB6D for ; Wed, 13 Dec 2006 02:05:38 +0100 (CET) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 3365E3CD0BB68 for ; Wed, 13 Dec 2006 02:05:38 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 12 Dec 2006 23:08:26 +0100 User-Agent: KMail/1.8.2 References: <1163545104.12931.49.camel@basalt> <200612052104.58254.okuji@enbug.org> <1165531179.8900.24.camel@basalt> In-Reply-To: <1165531179.8900.24.camel@basalt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612122308.26778.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.142450, version=0.17.2 Subject: Re: multiboot2: make multiboot header optional 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: Tue, 12 Dec 2006 22:08:36 -0000 On Thursday 07 December 2006 23:39, Hollis Blanchard wrote: > I thought we had two options: embedding tags, or ORing bits into an > embedded long. When I suggested embedding tags, you told me it was too > complicated so will cause developer errors. Have I misunderstood? I meant that the complexity of using bitfields plus a fixed-size structure is identical to that of using tags. But I bet that it is more complicated to use tags _by hand_. For me, "complex" and "complicated" are quite different. Besides how to make it look easier by predefined macros, please consider the spec itself. With bitfields and fixed-size fields, all you must remember is: - What bits mean what - How to order values passed to a boot loader With tags, you need to remember: - What tags mean what - What tag size is expected to each tag - What tags must be combined with a given tag If you generate tags by programming, I don't think the use of tags is more complicated. It can be even easier for a parser. However, when specifying tags by hand, I cannot believe that it is as straightforward as using fields. If you allow me to use a "big gun", I would tell you that most system programmers are used to fields, while they are not familar with writing tags. Okuji