From: Mikael Pettersson <mikpe@csd.uu.se>
To: johnstul@us.ibm.com, kai@tp1.ruhr-uni-bochum.de
Cc: Martin.Bligh@us.ibm.com, davej@suse.de,
linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: [Patch] tsc-disable_A5
Date: Sat, 15 Jun 2002 16:13:33 +0200 (MET DST) [thread overview]
Message-ID: <200206151413.QAA07923@harpo.it.uu.se> (raw)
On 14 Jun 2002 16:44:30 -0700, john stultz wrote:
>On Fri, 2002-06-14 at 16:29, Kai Germaschewski wrote:
>> I suppose you could it rewrite like
>>
>> ...
>> CONFIG_X86_WANT_TSC=y (or whatever)
>> ...
>>
>> if [ some_condition ]; then
>> define_bool CONFIG_X86_TSC n
>> else
>> define_bool CONFIG_X86_TSC $CONFIG_X86_WANT_TSC
>> fi
>>
>> Not exactly elegant, but it should work ;)
>
>Yep, my first release was done in a similar fashion, but Alan suggested
>the patch take on its current form. There may be cases where we want to
>know if we have a TSC even if we don't want to use them.
>
>Thread link:
>http://www.uwsg.iu.edu/hypermail/linux/kernel/0205.3/1188.html
I disagree with Alan's recommendation.
The real problem is that the kernel confuses a CPU-level property
(do the CPUs have TSCs?) with a system-level property (are the
TSCs present and in sync?). CONFIG_X86_TSC really describes the
latter property, for the former we have the cpu_has_tsc() macro.
IMO, Kai is right and a nicer fix is to change arch/i386/config.in to:
- s/CONFIG_X86_TSC=y/CONFIG_X86_CPU_HAS_TSC=y/
(this one can also be used as an optimisation to avoid runtime
cpu_has_tsc() checks)
- append a rule which derives CONFIG_X86_TSC from CONFIG_X86_CPU_HAS_TSC
and !multiquad
The other patch which adds an anti-CONFIG_X86_TSC to cancel the
first CONFIG_X86_TSC is so horribly hacky...
/Mikael
next reply other threads:[~2002-06-15 14:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-15 14:13 Mikael Pettersson [this message]
2002-06-19 13:58 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2002-06-14 21:53 Mikael Pettersson
2002-06-14 22:11 ` john stultz
2002-06-14 18:35 john stultz
2002-06-14 18:53 ` Benjamin LaHaise
2002-06-18 0:48 ` Kurt Garloff
2002-06-18 1:31 ` john stultz
2002-06-14 18:57 ` Dave Jones
2002-06-14 19:04 ` john stultz
2002-06-14 19:56 ` Dave Jones
2002-06-14 23:29 ` Kai Germaschewski
2002-06-14 23:44 ` john stultz
2002-06-24 2:09 ` Pavel Machek
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=200206151413.QAA07923@harpo.it.uu.se \
--to=mikpe@csd.uu.se \
--cc=Martin.Bligh@us.ibm.com \
--cc=davej@suse.de \
--cc=johnstul@us.ibm.com \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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®