Re: multiboot2

[phcoder]

Yoshinori K. Okuji wrote:
> 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?
On some platforms the number of features may be bigger
> 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.
I agree but specification should make such things less likely
> > > > > 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.
I don't know about alpha but on i386 cpu kernel needs only 4 things from 
 the bootloader to be totally firmware-independent: memory map, 
framebuffer info, rsdp and smbios address. So I propose to add tags for 
3 last things and make memory map required. This would encourage 
creation of OS working on all branches of i386 including coreboot
I think on many platforms it's possible to pass some number of 
parameters to make it firmware-independent too
> 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. 

Badram? Creepy firmwares?

> > > 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.
Implementation in grub2 matches neither version of the draft.
> > And what about encoding?
>
> Fine for me.
I updated the multibootdraft
> Regards,
> Okuji
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel


--

Regards
Vladimir 'phcoder' Serbinenko