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