Re: multiboot2

[phcoder <phcoder@gmail.com>]

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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko