Hi Steve, Le mercredi 18 mai 2011 Ã 12:07 -0500, Steve Calfee a Ãcrit : > 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 Thanks for your comments. Even though the use of cpu_is_ may not be the best approach, it is used extensively in OMAP code. Do you think that this situation needs to be fixed before accepting the patches for these two devices? Also, in the case of OMAP, runtime CPU identification is needed, for the reason Peter mentions. It is hard for me to see how it can be implemented using #ifdef only. Do you think that runtime CPU identification should be moved to the header containing the ifdeferry? Individual functions for different domains (audio, video, etc.) would still need to check at runtime if their devices are required. Perhaps having a single omap2plus_defconfig for all OMAP2/3/4/x/y/... devices is no longer convenient as more and more OMAP families arrive. What do you think? Regarding using a initrd, that applies only for loadable modules, but not for built-in modules, correct? BR, Ricardo -- 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
