On Tue, 31 Jan 2012, Catalin Marinas wrote: > Maybe we could factor out the CPU-specific settings from proc-v*.S > into a separate arch/arm/boot/preload directory. We keep proc-v*.S > entirely generic and the implementation-defined bits setting in the > preload code. You could have an option to link the preload with the > kernel but we could recommend that people run this code from > boot-loader before invoking the kernel. This code would be dependent > on platform and chosen at build-time. But the actual kernel image > would be generic. I'd recommend against that. Again, the reason is not technical but rather has to do with the tendency to laziness of human beings. So please let's not go there or it'll become the de facto standard. Furthermore, if this is risky to leave a vulnerable window by activating some workarounds later during the boot process, then the risk won't go away entirely by moving those workarounds a bit earlier. In which case the only real solution is to have them enabled by the bootloader before the cache is even turned on for the first time, and this is hardly Linux specific anyway. The whole idea behind having a generic kernel is all about distributions. If a generic kernel has to be distributed with a platform specific pre-kernel blob then we've gained nothing. Same goes for the DTB. Those platform specific blobs must be distributed _with_ the hardware and _not_ with the software distribution. Having the dts files in the kernel right now is only a convenience for the transition to device tree. Eventually they all will be removed from the tree when we get to a minimum of stability in the device tree implementation and the DTB will also have to come with the hardware along with the bootloader. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
