Subject: Re: linux-next: percpu tree build warning

From: Tejun Heo <[email-masked]>
Date: Wed, 25 Nov 2009 21:39:33 +0900

Hello,

11/25/2009 08:58 PM, Ingo Molnar wrote:
> percpu variables are basically in a special struct. It's not like you 
> can _ever_ access 'dr7' the percpu variable like that - it _always_ has 
> to go via a proper percpu wrapper construct. So this change is 
> needlessly obtrusive.

The only problem is that now the addresses can and need be handled as
value.  If we keep the prefix, we just end up with one set of
accessors which prepend prefix to the symbol string and another set
which are basically the same but lack any protection (we already have
them - this_cpu accessors).  The current for-next tree is sort of
caught up inbetween.  Once sparse warning cleanup sweep is complete,
all static specific accessors will be dropped.

> Really, guys, while the workaround is easy (a rename), this might be 
> going a bit too far. I already think that the recently introduced 
> limitation to name local percpu symbols globally sucked - but i'm not 
> sure whether this new rule of not allowing such clear and clean looking 
> code is acceptable.
>
> Percpu variables now pollute _both_ the global and the local namespace - 
> i dont think you can have it both ways.

I agree static local symbol requiring global uniqueness truly sucks
but this is a completely different issue.  This is making percpu
variables behave more sanely and the fallouts are few and linux-next
warning check is enough to detect the few.

Thanks.

-- 
tejun