From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Grgot-00065a-JW for mharc-grub-devel@gnu.org; Tue, 05 Dec 2006 15:23:15 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Grgor-00063l-Az for grub-devel@gnu.org; Tue, 05 Dec 2006 15:23:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Grgoq-00062s-Fn for grub-devel@gnu.org; Tue, 05 Dec 2006 15:23:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Grgoq-00062c-7X for grub-devel@gnu.org; Tue, 05 Dec 2006 15:23:12 -0500 Received: from [212.85.152.101] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Grgop-0000zk-TD for grub-devel@gnu.org; Tue, 05 Dec 2006 15:23:12 -0500 Received: from kotoba.oasis.nexedi.com (kotoba.oasis.nexedi.com [212.85.152.101]) by kotoba.storever.com (Postfix) with ESMTP id 8C3EB3CD54D03 for ; Wed, 6 Dec 2006 00:17:18 +0100 (CET) Received: from [??1] (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 69CED3CD54D02 for ; Wed, 6 Dec 2006 00:17:18 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Tue, 5 Dec 2006 21:23:10 +0100 User-Agent: KMail/1.8.2 References: <1163545104.12931.49.camel@basalt> <200612021827.31945.okuji@enbug.org> <1165250619.30343.17.camel@basalt> In-Reply-To: <1165250619.30343.17.camel@basalt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612052123.10177.okuji@enbug.org> X-Bogosity: No, tests=bogofilter, spamicity=0.443818, 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, 05 Dec 2006 20:23:13 -0000 On Monday 04 December 2006 17:43, Hollis Blanchard wrote: > It should be pretty clear that 32 bits are a finite number, and tags are > unlimited. In fact it's worse than that, since the bit partitioning > means we have far fewer available bits for any particular flag. Tags are also finite, too, theoretically speaking. :p If the number of bits is really a problem, it is even possible to make additional flags only when a bit in the original flags is set... Well, this is ugly, but this is the so-called tag structure as well, no? Seriously, I really don't think the number of bits could be fatal. You were advocating removing the header itself, then why would you expect so much extension in the future? > The bit numbering is also confusing, especially the partitioning of > meanings (this is required, this is requested, this is arch-specific, > this isn't). I agree with this part. We can make it better. > Finally, using flags for some things and tags for others is > inconsistent. I don't care. For OS developers, this inconsistency does not hurt them. As I mentioned earlier, it is annoying to write tags by hand, while generating tags is as easy as parsing a fixed structure for programs. If you don't believe this, ask somebody else which looks easier: .long multiboot_header .long _start .long _edata .long _end .long multiboot_entry or: .long HEADER_ADDRESS_TAG, 12, multiboot_header .long LOAD_START_ADDRESS_TAG, 12, _start .long LOAD_END_ADDRESS_TAG, 12, _edata .long BSS_END_ADDRESS_TAG, 12, _end .long ENTRY_ADDRESS_TAG, 12, multiboot_entry > > The extensibility argument alone is enough to seal it for me, especially > since the code can be written in such an error-free manner, as I've > demonstrated. Is it a good spec which forces one to use sample code to be error-free? Okuji