Re: my plan for Multiboot 2

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

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