Re: multiboot2: make multiboot header optional

["Yoshinori K. Okuji" <okuji@enbug.org>]

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