grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiboot2: make multiboot header optional


From: Hollis Blanchard
Subject: Re: multiboot2: make multiboot header optional
Date: Tue, 12 Dec 2006 22:18:19 -0600

On Tue, 2006-12-12 at 23:08 +0100, Yoshinori K. Okuji wrote:
> 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.

I'm willing to go along with this, since I realized that only a tiny
number of people will need to use this flags (and that number does not
include me :). It seemed to work for GRUB Legacy, so I guess it can work
here too.

My loader code doesn't currently read either tags or flags, and since
most people don't need this functionality I plan to check it in without
that; it can be added later as needed.

-Hollis





reply via email to

[Prev in Thread] Current Thread [Next in Thread]