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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
