Re: [patch] smp_processor_id() cleanup, 2.6.12-rc5

[Steven Rostedt]

On Thu, 2005-05-26 at 12:44 +0200, Ingo Molnar wrote:
> this patch implements a number of smp_processor_id() cleanup ideas that 
> Arjan van de Ven and i came up with.
> 
> the previous __smp_processor_id/_smp_processor_id/smp_processor_id API 
> spaghetti was hard to follow both on the implementational and on the 
> usage side.
> 
> some of the complexity arose from picking wrong names, some of the 
> complexity comes from the fact that not all architectures defined 
> __smp_processor_id.
> 
> in the new code, there are two externally visible symbols:
> 
>  - smp_processor_id(): debug variant.
> 
>  - raw_smp_processor_id(): nondebug variant. Replaces all existing
>    uses of _smp_processor_id() and __smp_processor_id(). Defined
>    by every SMP architecture in include/asm-*/smp.h.
> 
> there is one new internal symbol, dependent on DEBUG_PREEMPT:
> 
>  - debug_smp_processor_id(): internal debug variant, mapped to
>                              smp_processor_id().
> 
> also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new 
> lib/smp_processor_id.c file. All related comments got updated and/or 
> clarified.

Let me be the first to say "Thank you Ingo! (and Arjan)".  God, the fun
I had with _?_?smp_processor_id. The first time I got the bug message I
was "WTF", and then to figure out if I should use the _ or __ version.
I hope your patch gets in so that this will be much cleared up, and put
my effort in learning the difference between them all in vain.

I guess I should download the latest kernel and try it out.

Thanks again,

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/