public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 14:04:47 +0400	[thread overview]
Message-ID: <20080518100447.GF6948@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
| 

Eventually these helpers could look like this, objections?
---

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
}

static inline void __die_nmi(char *str, struct pt_regs *regs, int do_panic)
{
#ifdef CONFIG_X86_64
	die_nmi(str, regs, do_panic);
#else
	die_nmi(regs, str);
#endif
}

static inline int mce_in_progress(void)
{
#if defined(CONFIX_X86_64) && defined(CONFIG_X86_MCE)
	return atomic_read(&mce_entry) > 0;
#endif
	return 0;
}
---

they are pretty ugly anyway ;)

		- Cyrill -

  parent reply	other threads:[~2008-05-18 10:05 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
2008-05-18 10:04         ` Cyrill Gorcunov [this message]
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=20080518100447.GF6948@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox