Re: non-choice related config entries within choice

["Jan Beulich" <jbeulich@novell.com>]

>But one feature I really would like to see is named chocies so we can do stuff like:
>
>choice X86_PROCESSOR
>
>config GENERIC_PROCESSOR
>	bool "A generic X86 processor"
>endchoice
>
>
>...
>
>choice PPC_PROCESSOR
>
>config GENERIC_PROCESSOR
>	bool "A generic PowerPC processor
>
>endchoice
>
>The issue here is that we do not today allow the same config option
>to appear if more than one choice.

I want named choices, too, but for a different purpose (and not
unconditionally): Currently, a choice really can just be a selection
between individual boolean settings or (as the current intended
extension) a mixture of boolean and tristate values. String or
numerical values aren't permitted (and iirc they even cause the config
process to crash). Nevertheless there are a couple of example where
choosing between individual string or numeric values is intended (but
needs to be made work with the current infrastructure, meaning that
one first chooses between boolean values and then selects (or sets
through default values in prompt-less config options) the intended
string or numeric value.

What you want seems much more fundamental a change, and as I
understand it you really want the name just as a name space
separation mechanism.

>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
>endif
>
>if PPC
>source foo/bar/Kconfig
>endif
>
>Where we in foo/bar/Kconfig has a choice list.

That you be done with

if X86 || PPC
source foo/bar/Kconfig
endif

then, I would think (which should be the default anyway if you want a
Kconfig covering all architectures).

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

Jan