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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel