From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755037AbYERKKT (ORCPT ); Sun, 18 May 2008 06:10:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752066AbYERKKH (ORCPT ); Sun, 18 May 2008 06:10:07 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]:47048 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751073AbYERKKF (ORCPT ); Sun, 18 May 2008 06:10:05 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=HFVfXA7hZQqIR8Jxpoc2a+H+bhB96QhOYg7ZZnO4Vty5MgYu9fa1T9mKyP9Xtbfhu+coZjOJHpKS7BpZYbDsmMBlfiOFaMPwU+SC8qvfJ2vgOQNeZMFBIB3RwJsvJXM01AxoEJJKR/gyr633n/R6gX09nj+GKe/QXPDaNURASko= Date: Sun, 18 May 2008 14:09:55 +0400 From: Cyrill Gorcunov To: Thomas Gleixner Cc: Mikael Pettersson , "Maciej W. Rozycki" , Tom Spink , Ingo Molnar , "H. Peter Anvin" , LKML , Jiri Slaby , Andi Kleen Subject: Re: [RFC] x86: merge nmi_32-64 to nmi.c Message-ID: <20080518100955.GG6948@cvg> References: <20080517192200.GA6914@cvg> <7b9198260805171328u555eec17t3597f3378edbda88@mail.gmail.com> <18479.21161.437325.251769@harpo.it.uu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Thomas Gleixner - Sun, May 18, 2008 at 12:34:15AM +0200] | On Sat, 17 May 2008, Mikael Pettersson wrote: | > Maciej W. Rozycki writes: | > > On Sat, 17 May 2008, Tom Spink wrote: | > > | > > > static inline unsigned int get_nmi_count(int cpu) | > > > { | > > > #ifdef CONFIG_X86_64 | > > > return cpu_pda(cpu)->__nmi_count; | > > > #else | > > > return nmi_count(cpu); | > > > #endif | > > > } | > > > | > > > I know it introduces a lot of these conditionals, but at least there | > > > is one place to look for the get_nmi_count function, instead of | > > > searching for all variants of the function. | > > | > > Well, I suppose some header should provide a definition like: | > > | > > #ifdef CONFIG_X86_64 | > > #define cpu_x86_64 1 | > > #else | > > #define cpu_x86_64 0 | > > #endif | > > | > > and the you can remove the horrible #ifdef clutter and make the quoted | > > function look like: | > > | > > static inline unsigned int get_nmi_count(int cpu) | > > { | > > return cpu_x86_64 ? cpu_pda(cpu)->__nmi_count : nmi_count(cpu); | > > } | > > | > > Much better -- isn't it? | > | > IMO, no, the #ifdef is preferable. | > | > Why? Because the #ifdef is a very visible signal to the platform | > people that there are (in this case) subarch differences that force | > "clients" to behave differently on different subarchs. By removing | > the #ifdef you're IMO making it less likely for the platform people | > to take notice and work towards eliminating those differences. | | The #ifdef is a poor choice. Maciej is damned right, that the single | function with a clear distinction of the return value is better in | terms of readability and maintenance. | | As I said before, We can make this more visible with an uppercase | CONFIG_WHATEVER instaed of the innocent cpu_x86_64 one, but both | solutions are better than #ifdefs and provide simple grepable | patterns. | | The awareness of those differences does not depend at all on an | #ifdef. Developers who are aware of the platform differences prefer a | readable not ifdef poluted code base. People who need to be poked into | the difference via an #ifdef are probably not those who can actually | clean it up. | | Thanks, | | tglx | Btw Thomas, is there any reason why can't we add do_panic in die_nmi on 32bit? And that would help us to add "panic" boot option on 32bits as well. - Cyrill -