>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 -- 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/
