my plan for Multiboot 2

my plan for Multiboot 2

[Robert Millan]

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.

Here's my plan for Multiboot:

  - Release Multiboot 1 as a standalone package, with no modifications.  I will
    do this soon when I find some free time (and I think Vladimir had some
    cleanup done to the package that isn't yet merged).

  - Release a new revision of Multiboot 1, with only modifications that don't
    alter the spec.  I.e. GRUB Legacy continues to be compliant, and we don't
    change the signature.  These modifications would basically cope with the
    fact that Multiboot 1 is also usable on non-BIOS platforms, take advantage
    of modern 64-bit types to define equivalent structures, resolve some
    ambiguities, etc.

  - Release a new version of Multiboot 1, with only the modifications necessary
    for it to support non-i386 CPUs.  In principle, it should be possible to do
    this without affecting the i386 definitions.  Hence GRUB Legacy continues
    to be compliant.

  - Make loader/i386/multiboot.c CPU-independant, to the extent that this is
    possible.  The idea is that the most amount of code that can be reasonably
    shared, should be.

  - Release a new version of Multiboot, based on Multiboot 1, this time
    contemplating changes that break compatibility.  Proposed changes must
    be accompanied with a patch for our loader before they're committed to
    the spec.  The Multiboot 2 draft in the wiki is a good source of ideas
    for improvements, although not necessarily the only one.

  - Repeat last step untill we're satisfied with the result and can dub it
    as "Multiboot 2".

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: my plan for Multiboot 2

[Samuel Thibault]

Robert Millan, le Mon 07 Dec 2009 16:08:31 +0100, a écrit :
>   - Release a new revision of Multiboot 1, with only modifications that don't
>     alter the spec.  I.e. GRUB Legacy continues to be compliant, and we don't
>     change the signature.  These modifications would basically cope with the
>     fact that Multiboot 1 is also usable on non-BIOS platforms, take advantage
>     of modern 64-bit types to define equivalent structures, resolve some
>     ambiguities, etc.

I'm wondering about the multiboot_mod_list structure & 64bits: would
mod_start/end, cmdline and pad become 64bits?

Samuel

Re: my plan for Multiboot 2

[Robert Millan]

On Mon, Dec 07, 2009 at 05:53:29PM +0100, Samuel Thibault wrote:
> Robert Millan, le Mon 07 Dec 2009 16:08:31 +0100, a écrit :
> >   - Release a new revision of Multiboot 1, with only modifications that don't
> >     alter the spec.  I.e. GRUB Legacy continues to be compliant, and we don't
> >     change the signature.  These modifications would basically cope with the
> >     fact that Multiboot 1 is also usable on non-BIOS platforms, take advantage
> >     of modern 64-bit types to define equivalent structures, resolve some
> >     ambiguities, etc.
> 
> I'm wondering about the multiboot_mod_list structure & 64bits: would
> mod_start/end, cmdline and pad become 64bits?

I think long-term we should treat ia64 and amd64 as separate architectures.

Short-term we don't really support them, except to recognize and load amd64
ELF files.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: my plan for Multiboot 2

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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?
The only major feature of multiboot2 is tagged mbi but it can be added
in compatible way too.
> Here's my plan for Multiboot:
>
>   - Release Multiboot 1 as a standalone package, with no modifications.  I will
>     do this soon when I find some free time (and I think Vladimir had some
>     cleanup done to the package that isn't yet merged).
>   
I'll merge it when time permits.
>   - Release a new revision of Multiboot 1, with only modifications that don't
>     alter the spec.  I.e. GRUB Legacy continues to be compliant, and we don't
>     change the signature.  These modifications would basically cope with the
>     fact that Multiboot 1 is also usable on non-BIOS platforms, take advantage
>     of modern 64-bit types to define equivalent structures, resolve some
>     ambiguities, etc.
>
>   
Good points. MAny kernels can be leveraged this way to pan-i386
>   - Release a new version of Multiboot 1, with only the modifications necessary
>     for it to support non-i386 CPUs.  In principle, it should be possible to do
>     this without affecting the i386 definitions.  Hence GRUB Legacy continues
>     to be compliant.
>
>   - Make loader/i386/multiboot.c CPU-independant, to the extent that this is
>     possible.  The idea is that the most amount of code that can be reasonably
>     shared, should be.
>
>   
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 specifically want non-x86 to use only tagger
multiboot header and mbi because of their expandability (we'll need it
on CPUs like mips where theoretically same kernel could run on a wide
range of hardware but needs a lot info for this, more than 8 features
per category permit). Another problem is the difficulty to relocate
non-tagged mbi. I would like eliminate this problem before going to non-x86
>   - Release a new version of Multiboot, based on Multiboot 1, this time
>     contemplating changes that break compatibility.  Proposed changes must
>     be accompanied with a patch for our loader before they're committed to
>     the spec.  The Multiboot 2 draft in the wiki is a good source of ideas
>     for improvements, although not necessarily the only one.
>
>   - Repeat last step untill we're satisfied with the result and can dub it
>     as "Multiboot 2".
>
>   


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



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

Re: my plan for Multiboot 2

[Robert Millan]

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.

> 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?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: my plan for Multiboot 2

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: my plan for Multiboot 2

[Robert Millan]

On Wed, Dec 09, 2009 at 11:17:54PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >> 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

It's not essential that we add non-x86 support first.  I only suggested it
because then non-x86 platforms wouldn't have to wait for the whole drafting
process, and I wouldn't want to discuss spec decisions with the pressure of
having it ready ASAP in order to support new platforms.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: my plan for Multiboot 2

[BVK Chaitanya]

I don't have much knowledge in multiboot yet, but this case comes to my mind:

Since GRUB2 is extensible (using modules), over time third party
modules would be developed and they may want to pass their own
parameters to kernels;  so we should provide some scheme to
differentiate standard (i.e, multiboot) parameters vs. non-standard
(i.e, third-party) parameters.



regards,
-- 
bvk.chaitanya

Re: my plan for Multiboot 2

[Bogdan]

Is it just me or does this whole thing on abandoning Multiboot 2 seem like a terrible idea? (That's a retorical question since I've already talked to several people in the OSDev community about it.) The only reason why people still use Multiboot is because it's the best we've got. It's not flexible and it's way behind the needs of current OSes.

Instead of several versions of Multiboot 1 popping up for other CPU architectures we could just have Multiboot 2. One day people will finally realise that no one can cope with Multiboot 1 anymore and by then we'll need to support both Multiboot 1 and Multiboot 2 in all kernels/boot loaders even for non-x86 architectures.

Cheers,
Bogdan



      

Re: my plan for Multiboot 2

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Bogdan wrote:
> Is it just me or does this whole thing on abandoning Multiboot 2 seem like a terrible idea? (That's a retorical question since I've already talked to several people in the OSDev community about it.) The only reason why people still use Multiboot is because it's the best we've got. It's not flexible and it's way behind the needs of current OSes.
>
>   
It's a misunderstanding. We don't abandon multiboot2. The draft we want
to discard isn't much better than multiboot1. But we will develop
multiboot1 in a way to become multiboot2 and to correspond to the need
of OSes. The best you can push it is by helping us with describing and
implementing features you need. As Robert said our resources are scarce
that's why just a suggestion is probably not enough, you need to do things.
> Instead of several versions of Multiboot 1 popping up for other CPU architectures we could just have Multiboot 2. One day people will finally realise that no one can cope with Multiboot 1 anymore and by then we'll need to support both Multiboot 1 and Multiboot 2 in all kernels/boot loaders even for non-x86 architectures.
>
>   
I prefer to have tagged multiboot before going non-x86
> Cheers,
> Bogdan
>
>
>
>       
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


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



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

Re: my plan for Multiboot 2

[Robert Millan]

On Sun, Dec 13, 2009 at 11:16:11PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Bogdan wrote:
> > Is it just me or does this whole thing on abandoning Multiboot 2 seem like a terrible idea? (That's a retorical question since I've already talked to several people in the OSDev community about it.) The only reason why people still use Multiboot is because it's the best we've got. It's not flexible and it's way behind the needs of current OSes.
> >
> >   
> It's a misunderstanding. We don't abandon multiboot2. The draft we want
> to discard isn't much better than multiboot1. But we will develop
> multiboot1 in a way to become multiboot2 and to correspond to the need
> of OSes.

Definitely.  We're driven by the needs of OS kernel developers.  We're not
going to let legacy junk get in the way.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: my plan for Multiboot 2

[Robert Millan]

On Thu, Dec 10, 2009 at 12:36:24PM +0530, BVK Chaitanya wrote:
> I don't have much knowledge in multiboot yet, but this case comes to my mind:
> 
> Since GRUB2 is extensible (using modules),

Modules don't really make GRUB extensible.  We don't make any promises about
ABI and it's very impractical to provide extensions as modules.

However, since it's free software and everyone can modify it, it's easy to
extend it at source level.  The grub-extras project does this.  Also, some
basic support in the build system (grep for GRUB_CONTRIB) makes this very
straightforward.

> over time third party
> modules would be developed and they may want to pass their own
> parameters to kernels;  so we should provide some scheme to
> differentiate standard (i.e, multiboot) parameters vs. non-standard
> (i.e, third-party) parameters.

OTOH, with Multiboot spec we need to be more careful.  I'm wary of it becoming
"balkanized" by too many third party extensions.  This doesn't mean we can't
implement extensions which are not in the spec in very specific situations
(e.g. kernel of OpenSolaris is not spec compliant), though.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi