Re: multiboot2

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

On Tuesday 07 April 2009 10:18:30 phcoder wrote:
> Yoshinori K. Okuji wrote:
> >>> 1) double the size of flags. 8 features per category seems to be few.
> >
> > I do not agree on this. As you can see, most bits are still undefined
> > after over 10-year usage of the Multiboot Specification. I do not want to
> > change it without any real issue.
>
> The difference is that multiboot2 is meant to be portable

Yes, but so?

> > There's a good reason to make it optional. If you see GRUB only, you will
> > think that this behavior should be always implemented, but some boot
> > loaders are more nervous about the code size, so they want to skip as
> > many features as they can. In fact, AFAIK, Etherboot didn't implement
> > sorting in its Multiboot support.
>
> What I want is to avoid is the bitrot as with multiboot1 when due to
> different issues some kernels boot only with some booters. Such a
> situation defeats the purpose of the standard

Not really. Even with the most strict spec possible, it is always possible to 
depend on implementation details which are not part of the spec. So, if an OS 
image does boot only with some implementations, it is a fault in the OS 
image, and the OS image should be fixed.

> >>> 6) memory map. "<!> Tags of this type should be omitted on
> >>> architectures where the OS is able to retrieve this information from
> >>> firmware. (Doing do will encourage OS portability across bootloaders,
> >>> and simplify GRUB development and maintenance.) "
> >>> This contradicts the goal of easier OS developement and may result in
> >>> semi-compatible OS and bootloaders. Additionally I think that
> >>> eliminating the necessity of use of firmware from OS is a good thing
> >>> and allows easier porting between architectures differing only by
> >>> firmware
> >
> > It is hard for me to say which is better.
> >
> > In reality, every OS needs to interact with underlying firmware more or
> > less to be functional (power control, interrupt handling, etc.). So
> > giving a memory map does not eliminate the necessity of interactions with
> > firmware anyway.
>
> This isn't entirely true. Most of OS use their own firmware-independent
> drivers for most devices.

For device drivers, yes. For other things, not always. For instance, on Alpha, 
you need to use the firmware to enter the privileged mode. AFAIK, no other 
choice.

From my point of view, the conclusion should be based on whether a boot loader 
may want to provide a memory map different from what firmware thinks. If yes, 
we have a good reason to make it required. If no, not much.

> > Seemingly, someone made a bad change on the draft, so the information is
> > lost:
> >
> > http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22
> >
> > Hollis's idea was to use the same format as for modules to give
> > information about an OS image. A part of this change must be reverted. It
> > is wrong to adopt the spec to the implementation.
>
> It's ok with me. Quick look through the code suggests that probably
> kernel tag is created with type MODULE and that it also has an
> additional field type. I will check it tomorrow but it looks like a bug
> somewhere

Hmm.

> And what about encoding?

Fine for me.

Regards,
Okuji