Re: my plan for Multiboot 2

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]

Robert Millan wrote:
> On Wed, Dec 09, 2009 at 10:51:03PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> Robert Millan wrote:
>>     
>>> Hi,
>>>
>>> We have an obvious problem with the Multiboot 2 loader:  It's in
>>> severe bitrot.  Nobody complains because nobody uses it, which is
>>> understandable given that nobody programs for MB2, because it's not
>>> ready (both in spec and in implementation), and we don't improve it
>>> because nobody complains, etc.  You get the point :-)
>>>
>>> I think the approach that was taken has proven wrong.  It might have
>>> worked with more manpower, but our time resources are scarce and we have
>>> other priorities.  In my opinion, as things stand now it is best if
>>> Multiboot 2 is developed by piggybacking on Multiboot 1 rather than as an
>>> isolated effort.  This idea is twofold: both in spec and in implementation.
>>>
>>>   
>>>       
>> Do you plan on removing multiboot2 loader from grub2 and marking
>> multiboot2 draft as abandonded?
>>     
>
> I don't know.  Do you think this would be necessary?  I was thinking we could
> gradually replace it in parallel, but I'm open to ideas/suggestions.
>
>   
If I have multibootdraft correctly in head the only 2 new things are
tagged mbi and multi-CPU.
We can add tagged MBI to multiboot1 in compatible way but we have to
rethink howexactly it will look like - current draft is contradictory
and so it's easier to make new one inspired by old ideas than try to
rescue old one.
Although powerpc is defined in multiboot2 draft it's not implemented in
grub2. Safe to assume nobody used it
>> I think cpu-independency should come after possible incompatible changes
>> since if we bring bad but compatible decision to non-x86 then it will be
>> difficult to eradicate.
>>     
>
> I don't understand very well;  could you give an example of problematic
> situation?
>
>   

The most obvious are feature bits: we have statically allocated 32 bits,
16 optional, 16 required features. On platforms where OS needs a lot of
hardware info it may be too few.
Another problem is pointer-rich mbi which needs complicated processing
before it can be relocated. Since often it has to be done before
launching C code it makes startup assembly unnecessarily complex


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]