From: Ingo Molnar <mingo@elte.hu>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: fix numaq_tsc_disable calling
Date: Sun, 13 Jul 2008 08:48:03 +0200 [thread overview]
Message-ID: <20080713064803.GB13949@elte.hu> (raw)
In-Reply-To: <86802c440807122331t60ff315dn698e6c04bce2599@mail.gmail.com>
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Sat, Jul 12, 2008 at 11:25 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >
> >> if (cpu_has_bts)
> >> ptrace_bts_init_intel(c);
> >> +
> >> +#ifdef CONFIG_X86_NUMAQ
> >> + numaq_tsc_disable();
> >> +#endif
> >
> > could you please one more cleanup and hide the CONFIG_X86_NUMAQ in the
> > header file, so that we can just call numaq_tsc_disable() without an
> > #ifdef?
> >
> > also, that TSC quirk should probably be turned into an explicit quirk
> > function pointer initialized by the early-init NUMAQ code and left NULL
> > by everything else - like we it on visws. See include/asm-x86/setup.h:
> >
> > /*
> > * Any setup quirks to be performed?
> > */
> > extern int (*arch_time_init_quirk)(void);
> > extern int (*arch_pre_intr_init_quirk)(void);
> > extern int (*arch_intr_init_quirk)(void);
> > extern int (*arch_trap_init_quirk)(void);
> > extern char * (*arch_memory_setup_quirk)(void);
> > extern int (*mach_get_smp_config_quirk)(unsigned int early);
> > extern int (*mach_find_smp_config_quirk)(unsigned int reserve);
> >
> > the goal is to offload all non-standard setup that is not a reasonable
> > deviation of some of the major vendors to such a quirk handler. Quirks
> > are a lot easier to maintain and a lot easier to think about - they can
> > be just by-line functionality to the main body of default behavior.
>
> looks neat.
>
> can we use one big arch_mach_quicks struct..?
yeah, good idea.
Perhaps name it x86_quirks to make it really short to check it. Then
consolidate all of our scattered quirks into it. I bet we could get some
of the paravirt details into this as well.
So something like:
if (arch_time_init_quirk) {
/*
* A nonzero return code does not mean failure, it means
* that the architecture quirk does not want any
* generic (timer) setup to be performed after this:
*/
if (arch_time_init_quirk())
return;
}
Would turn into:
if (x86_quirks.time_init) {
if (x86_quirks.time_init())
return;
}
[ ... regular init ...]
So that the return code of x86_quirks.time_init() can be used to signal
whether a quirk wants the regular init to run or not. In the VisWS case
this allowed further consolidation.
We dont want any chaining (i.e. dont use notifiers or anything) as these
quirks are all exclusive anyway.
Ingo
prev parent reply other threads:[~2008-07-13 6:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-13 5:52 Yinghai Lu
2008-07-13 6:25 ` Ingo Molnar
2008-07-13 6:31 ` Yinghai Lu
2008-07-13 6:48 ` Ingo Molnar [this message]
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=20080713064803.GB13949@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=yhlu.kernel@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
all inboxes | Powered by JetHome®