From: Len Brown <len.brown@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: marcelo@parcelfarce.linux.theplanet.co.uk,
Marcelo Tosatti <marcelo.tosatti@cyclades.com.br>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: HT not working by default since 2.4.22
Date: 25 Sep 2003 23:37:43 -0400 [thread overview]
Message-ID: <1064547463.2981.833.camel@dhcppc4> (raw)
In-Reply-To: <3F738288.5060304@pobox.com>
> Unfortunately CONFIG_ACPI_HT_ONLY outside and independent of CONFIG_ACPI
> proved a bit confusing.
It was outside, but it wasn't independent -- and _that_ I think was the
source of confusion.
CONFIG_ACPI depended on CONFIG_ACPI_HT. This looked good on paper
because CONFIG_ACPI_HT is a sub-set of CONFIG_ACPI...
But people who wanted ACPI but didn't want HT (eg. everybody with a PIII
laptop...) were perplexed that they had to "enable HT" in order to get
ACPI.
> How about the more simple CONFIG_HYPERTHREAD or CONFIG_HT?
>
> If enabled and CONFIG_SMP is set, then we will attempt to discover HT
> via ACPI tables, regardless of CONFIG_ACPI value.
Yes, except I think we should keep the name CONFIG_ACPI_HT_ONLY since it
says exactly what it does.
Hopefully I can make it looke clear in the menus --
I think on the config menus for CONFIG_ACPI_HT_ONLY and CONFIG_ACPI
should be mutually exclusive.
> Or... (I know multiple people will shoot me for saying this) we could
> resurrect acpitable.[ch], and build that when CONFIG_ACPI is disabled.
The question about configs is independent of the acpitable.[ch] vs
table.c implementation. No, we should not return to maintaining two
copies of the acpi table code.
thanks,
-Len
next prev parent reply other threads:[~2003-09-26 3:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-24 21:56 HT not working by default since 2.4.22 Brown, Len
2003-09-24 23:12 ` Tomas Szepe
2003-09-25 13:33 ` marcelo
2003-09-26 0:04 ` Jeff Garzik
2003-09-26 3:37 ` Len Brown [this message]
2003-09-26 3:49 ` Jeff Garzik
2003-09-27 15:26 ` Herbert Poetzl
[not found] <BF1FE1855350A0479097B3A0D2A80EE0CC870C@hdsmsx402.hd.intel.com>
2003-09-28 10:43 ` Tomas Szepe
2003-09-28 10:46 ` Tomas Szepe
2003-09-29 1:41 ` Len Brown
2003-09-29 5:29 ` Tomas Szepe
-- strict thread matches above, loose matches on Subject: below --
2003-09-26 4:54 Brown, Len
2003-09-26 7:44 ` Jan Evert van Grootheest
2003-09-26 17:38 ` Len Brown
[not found] ` <3F73EE77.3000906-R6hnfgSw+1uEVqv0pETR8A@public.gmane.org>
2003-09-30 5:27 ` Len Brown
2003-09-30 5:27 ` Len Brown
2003-09-26 1:13 Nakajima, Jun
2003-09-22 17:28 Brown, Len
2003-09-22 17:55 ` Jeff Garzik
2003-09-22 14:41 Nakajima, Jun
2003-09-22 9:00 Marcelo Tosatti
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=1064547463.2981.833.camel@dhcppc4 \
--to=len.brown@intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com.br \
--cc=marcelo@parcelfarce.linux.theplanet.co.uk \
/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.