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