On Mon, Apr 4, 2011 at 8:50 AM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Mon, 4 Apr 2011, Eric Miao wrote: > >> >> * 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... :-) > > BIOS/firmware/bootloader. It's all the same thing when it comes to > updating them in deployed hardware: it is harder and much risquier than > updating the kernel or some DT data in the bootloader's environment. > And there is real danger of version skews that were never tested and > planned.
+1 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
