From: Randy Dunlap <randy.dunlap@oracle.com>
To: "James C. Georgas" <jgeorgas@georgas.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: broken ACPI NUMA config option
Date: Sun, 09 Sep 2007 10:32:09 -0700 [thread overview]
Message-ID: <46E42E19.4040701@oracle.com> (raw)
In-Reply-To: <1189345287.7365.23.camel@Tachyon.home>
James C. Georgas wrote:
> On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote:
>>> For example, you would only need to specify one "select" directive in
>>> X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
>>> would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
>>> on what it needed.
>> That is highly desirable IMO. Not having that is one of the things
>> that makes using 'select' "evil."
>>
>> Have you looked at the code and given any thought to implementing this?
>>
>
> I'd like to take a run at it. The only issue I foresee is what to do
> about multiple OR dependencies. There are some kconfig options that
> depend on at least one of a set of specified dependencies. For example,
> is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL
> is selected? So do we abort, select one, or select all dependencies?
It's a logical OR, meaning one or more of them is enabled.
I expect that there are some places that enabling all dependencies
would very much be the wrong thing to do, and choosing only one is
just a wild guess, so it looks like you would have to abort, with a
helpful message.
> Maybe I'm misunderstanding the usage of || here though. I'm assuming
> inclusive OR.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2007-09-09 17:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-08 22:51 broken ACPI NUMA config option James C. Georgas
2007-09-08 22:54 ` James C. Georgas
2007-09-08 23:33 ` James C. Georgas
2007-09-09 1:09 ` Randy Dunlap
2007-09-09 1:16 ` Randy Dunlap
2007-09-09 3:48 ` James C. Georgas
2007-09-09 4:24 ` Yinghai Lu
2007-09-09 5:00 ` Randy Dunlap
2007-09-09 13:41 ` James C. Georgas
2007-09-09 17:32 ` Randy Dunlap [this message]
2007-09-09 1:22 ` James C. Georgas
2007-09-09 9:07 ` Andi Kleen
2007-09-09 13:19 ` [PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options James C. Georgas
2007-09-09 13:46 ` Andi Kleen
2007-09-09 18:43 ` James C. Georgas
-- strict thread matches above, loose matches on Subject: below --
2007-09-09 2:36 broken ACPI NUMA config option James C. Georgas
2007-09-09 7:06 ` Sam Ravnborg
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=46E42E19.4040701@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=jgeorgas@georgas.ca \
--cc=linux-kernel@vger.kernel.org \
/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.