>> * And very hardware specific code moved out to a controllable place, >> i.e. something like BIOS > > Sorry, but I must vehemently disagree here. BIOSes are a problem for > Open Source, not a solution. On X86 they use BIOS services only when > there is simply no other choice, because the BIOS is too often buggy and > it is more difficult and risky to update than the kernel. > > If you rely on the BIOS to do X, it will work when the BIOS gets it > right. If you do X yourself, it will work whether or not the BIOS gets > it right. This means that if there's even one BIOS version you have to > deal with out there that gets X wrong, you have to do it yourself and > then there is no incentive to rely on the BIOS even in the cases where > it does get it right so to maintain only one code path. > > And relying on a BIOS could make many kernel improvements impossible to > implement as the execution context assumed by the BIOS may not be > guaranteed anymore (think about UP vs SMP, different preemption modes, > different realtime kernel modes, etc.) And of course it is impossible > to anticipate what execution context and requirements the kernel might > need in the future, hence this can't be provisioned for (and much less > validated) into the BIOS design in advance.
Not BIOS exactly, since we don't have BIOS for ARM. The problem with BIOS is that we don't have control, and when it's wrong we have nowhere to fix it. There are some ways out - e.g. if u-boot is standardized, we can definitely move part of the non-generic code there. Or I'm actually still thinking about using kernel as a bootloader, though not very clear on how, and we may still end up placing crap there... :-) _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
