[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 11 Apr 2009 20:56:15 +0200
Thunderbird 22.214.171.124 (X11/20090318)
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
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
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
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
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
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
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
Implementation in grub2 matches neither version of the draft.
And what about encoding?
Fine for me.
I updated the multibootdraft
Grub-devel mailing list
Vladimir 'phcoder' Serbinenko