On 05/17/11 22:41, Peter Ujfalusi wrote: > On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote: >> I think the generally accepted method of doing stuff like this is to >> have the ifdeffery in a header file where a inline code segment is >> defined if it applies to the processor being built. If the code does not >> apply to the model being built, a null #define is used, which does not >> take any space. > > We have for example omap2plus_defconfig, which include support for wide range > of OMAP based devices, with different CPUs (OMAP2/3/4). > So we need to have runtime distinction of the CPU we are running (since we run > the same kernel binary on OMAP2/3/4). > Hi Peter, I am not trying to start a flame war here, especially not with you really helpful people. The preferred header contained ifdeffery does not exclude the possibility of having multiple options selected, even at run time. It also can prevent multi cpu code bloat if it is not wanted. Alternatively, X86 distributions such as Ubuntu already deal with multiple arches (within the base arch intel/amd), using initrd type startups. Also the current "cpu_is" stuff is not very scalable, when TI gets to Omap42, or even slightly smaller such as Omap5, the untidiness of the current technique will become even more of a problem. Regards, Steve -- 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
