Re: multiboot2

[Vladimir 'phcoder' Serbinenko]

On Sat, Apr 11, 2009 at 8:56 PM, phcoder<address@hidden> wrote:
> 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
Additionally this format is hard to extend in cross-platform way.
Let's say we define new header on powerpc which takes bytes x to x+10
and a tag for i386 which takes bytes x to x+12 then we want to define
a new crossplatform tag. Where to we put it? Why not just use the same
format for multiboot header and multiboot info? It will make the job
of bootloader easier (handling one format instead of 2).
>>
>> 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
Recently we experienced the problem with OSes assuming different
details about specification. Of course it's bugs but bugs which are
difficult to find. Standard is here to decrease developpement time,
not increase it.
>>>>>>
>>>>>> 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
What about reserving a tag which will contain a copy of smbios anchor
and another for containing a copy of rsdp?
> 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?
Implementing memory map passing from bootloader side is cheap -
bootloader needs to know it anyway.
>>
>> Regards,
>> Okuji
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git