LKML Archive on
help / color / mirror / Atom feed
From: Sam Ravnborg <>
To: Jan Beulich <>
Cc: Roman Zippel <>,
	Randy Dunlap <>,,
Subject: Re: non-choice related config entries within choice
Date: Wed, 16 Jan 2008 12:52:33 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jan 16, 2008 at 11:18:38AM +0000, Jan Beulich wrote:
> Roman,
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not really belonging to the choice are inside
> the choice scope (drivers/usb/gadget/Kconfig, arch/ppc/Kconfig, and
> arch/mips/Kconfig are where I found such cases, and I hope this is a
> complete list).
> The question is: Is it intended for this to work the way it used to, or
> is it rather reasonable to change these scripts so that stuff dependent
> upon the choice selection is being dealt with outside the choice scope?

Hi Jan.

I will let Roman answer your question..

But one feature I really would like to see is named chocies so we can do stuff like:

choice X86_PROCESSOR

	bool "A generic X86 processor"



	bool "A generic PowerPC processor


The issue here is that we do not today allow the same config option
to appear if more than one choice.
This is a mandatory feature before we can do a Kconfig covering all architectures.
I guess there are other issues when we do:

if X86
source foo/bar/Kconfig

if PPC
source foo/bar/Kconfig

Where we in foo/bar/Kconfig has a choice list.

I just wanted to raise this now that you anyway are looking into choice
related issues.


  reply	other threads:[~2008-01-16 11:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 11:18 Jan Beulich
2008-01-16 11:52 ` Sam Ravnborg [this message]
2008-01-16 13:46   ` Jan Beulich
2008-01-16 13:50     ` Sam Ravnborg
2008-01-19  4:44   ` Roman Zippel
2008-01-19  4:36 ` Roman Zippel

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: non-choice related config entries within choice' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).