[PATCH] powerpc: merge include/asm/cputable.h

Kumar Gala kumar.gala at freescale.com
Fri Sep 16 03:44:29 EST 2005


I get the idea now, how about we make CPU_FTR_ALWAYS &  
CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to  
define CPU_FTR_POSSIBLE if they want to.

I see the classes of for FTR_POSSIBLE: CLASSIC_PPC, 8xx, 4xx, FSL- 
BOOKE, PPC64 (maybe more subclasses here).

The hugh enum while useful, is just really ugly and I can't believe  
it's worth it for the ~60 cases we are using cpu_has_feature() in.

- kumar

On Sep 14, 2005, at 6:58 PM, Arnd Bergmann wrote:

> On Middeweken 14 September 2005 21:11, Kumar Gala wrote:
>
>> I not sure I understand what the introduction of the enum's gets us.
>>
>>
> It doesn't have to be an enum, it could just as well be a #define,
> if we find that to be better in some way (maybe compile-time).
>
> The general idea is to convert run-time checks into compile-time
> checks in order to improve the running kernel. If you have
>
> // start code
> enum {
>     FEATURE_1 = 1,
>     FEATURE_2 = 2,
>     PLATFORM_1 = FEATURE_1,
>     PLATFORM_2 = FEATURE_2,
>     PLATFORM_3 = FEATURE_1 | FEATURE_2,
>     FEATURE_POSSIBLE =
> #ifdef CONFIG_PLATFORM_1
>         PLATFORM_1 |
> #endif
> #ifdef CONFIG_FEATURE_2
>         PLATFORM_2 |
> #endif
> #ifdef CONFIG_FEATURE_3
>         PLATFORM_3 |
> #endif
>         0,
>     FEATURE_ALWAYS =
> #ifdef CONFIG_PLATFORM_1
>         PLATFORM_1 &
> #endif
> #ifdef CONFIG_PLATFORM_2
>         PLATFORM_2 &
> #endif
> #ifdef CONFIG_PLATFORM_3
>         PLATFORM_3 &
> #endif
>         FEATURE_POSSIBLE,
> };
>
> static inline int have_feature(unsigned long feature)
> {
>     return (FEATURE_ALWAYS & feature) ||
>            (FEATURE_POSSIBLE & runtime_feature & feature);
> }
>
> int foo();
> int bar();
> int main(void)
> {
>     if (have_feature(FEATURE_1))
>         return foo();
>     if (have_feature(FEATURE_2))
>         return bar();
>     return 0;
> }
> // end code
>
> Then gcc will produce optimal object code for any combination
> of CONFIG_PLATFORM_{1,2,3}. Of course I have to admit that the
> header file is not exactly elegant ;-).
>
>     Arnd <><
>




More information about the Linuxppc-dev mailing list