my plan for Multiboot 2

[Robert Millan <rmh@aybabtu.com>]

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."