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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
