From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mikael Pettersson <mikpe@it.uu.se>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Tom Spink <tspink@gmail.com>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Jiri Slaby <jirislaby@gmail.com>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC] x86: merge nmi_32-64 to nmi.c
Date: Sun, 18 May 2008 10:24:26 +0400 [thread overview]
Message-ID: <20080518062426.GA6948@cvg> (raw)
In-Reply-To: <alpine.LFD.1.10.0805180023100.18798@apollo.tec.linutronix.de>
[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
|
Thanks to all for catching this nit. Actually I was using single
function definition with #ifdef inside at first attempt. But the
result was a too ugly imho, so I switched in the definition form
you see now. If single defs is preferrable - no problem, will change
it. Anyway, I found there are some additional patches in Ingo's tip
tree so I have to remake my patch completely. So, as only I've got
it done - will send to LKML again for your justice ;)
- Cyrill -
next prev parent reply other threads:[~2008-05-18 6:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-17 19:22 [RFC] x86: merge nmi_32-64 to nmi.c Cyrill Gorcunov
2008-05-17 20:28 ` Tom Spink
2008-05-17 20:52 ` Maciej W. Rozycki
2008-05-17 21:40 ` Thomas Gleixner
2008-05-18 7:25 ` Jeremy Fitzhardinge
2008-05-18 7:38 ` Cyrill Gorcunov
2008-05-18 8:33 ` Jeremy Fitzhardinge
2008-05-18 8:47 ` Cyrill Gorcunov
2008-05-18 9:13 ` Cyrill Gorcunov
2008-05-18 9:09 ` Thomas Gleixner
2008-05-18 9:35 ` Cyrill Gorcunov
2008-05-18 18:08 ` Adrian Bunk
2008-05-18 18:13 ` Andi Kleen
2008-05-18 18:35 ` Jeremy Fitzhardinge
2008-05-18 19:13 ` Andi Kleen
2008-05-19 14:27 ` Cyrill Gorcunov
2008-05-18 18:33 ` Jeremy Fitzhardinge
2008-05-18 19:29 ` Adrian Bunk
2008-05-18 19:51 ` Jeremy Fitzhardinge
2008-05-18 18:38 ` Maciej W. Rozycki
2008-05-18 20:40 ` Adrian Bunk
2008-05-18 10:15 ` Andi Kleen
2008-05-18 10:20 ` Cyrill Gorcunov
2008-05-18 10:25 ` Andi Kleen
2008-05-18 10:29 ` Cyrill Gorcunov
2008-05-18 12:07 ` Tom Spink
2008-05-18 12:10 ` Cyrill Gorcunov
2008-05-17 21:48 ` Mikael Pettersson
2008-05-17 22:34 ` Thomas Gleixner
2008-05-18 6:24 ` Cyrill Gorcunov [this message]
2008-05-18 10:04 ` Cyrill Gorcunov
2008-05-18 10:09 ` Cyrill Gorcunov
2008-05-19 18:07 ` Cyrill Gorcunov
2008-05-19 18:41 ` Cyrill Gorcunov
2008-05-21 7:41 ` Cyrill Gorcunov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080518062426.GA6948@cvg \
--to=gorcunov@gmail.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mikpe@it.uu.se \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tspink@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.