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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to