From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: linux-next: percpu tree build warning Date: Fri, 27 Nov 2009 15:31:00 +0900 Message-ID: <4B0F7224.9020509@kernel.org> References: <20091125214219.f37935e8.sfr@canb.auug.org.au> <4B0D23A6.8040902@kernel.org> <20091125134058.GA9097@elte.hu> <200911270846.02717.rusty@rustcorp.com.au> <20091127054128.GC13914@elte.hu> <4B0F6A67.9010706@kernel.org> <20091127062001.GA22149@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from hera.kernel.org ([140.211.167.34]:40358 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbZK0Gbd (ORCPT ); Fri, 27 Nov 2009 01:31:33 -0500 In-Reply-To: <20091127062001.GA22149@elte.hu> Sender: linux-next-owner@vger.kernel.org List-ID: To: Ingo Molnar Cc: Rusty Russell , Stephen Rothwell , Fr??d??ric Weisbecker , Peter Zijlstra , Christoph Lameter , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton Hello, Ingo. > At least to me a typo like this would stick out like a sore thumb during > review. Yeah, maybe, but it still shows why reusing the same name for global and local variables behind compiler's back is a bad idea. > I'd recognize ®1 as a stack local variable immediately, and when i > see it being used in this_cpu_inc() i'd go 'huh' immediately. > > OTOH, the two examples of confusion i gave you in my previous mail would > be far less obvious. The 'visual distance' to a percpu variable > definition is greater (it's at least file scope in 95% of the cases), so > i wouldnt be able to 'see' which the percpu variables are, from a code > context. With proper __percpu annotations (which we desparately need for dynamic percpu pointers anyway) the 'visual distance' should remain fine in most cases, I think. If we can manage the separate namespace thing without adding confusion regarding different types of accessors and the actually non-existing but yet visible differences between static and dynamic percpu variables, I think it would be good. But it costs us quite a bit and __percpu sparse annotation has almost complete coverage over the issue including the visible queue telling that something is percpu. So, given that, to me __percpu seems like a much better way to do it. Thanks. -- tejun