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
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.
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.
I just wanted to raise this now that you anyway are looking into choice
related issues.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
