Re: non-choice related config entries within choice
Hi, On Wed, 16 Jan 2008, Sam Ravnborg wrote: > 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. What I have in mind is slightly different, above choices would simply be called PROCESSOR, which would tell kconfig that all choices belong to the same group. bye, Roman -- 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/
Re: non-choice related config entries within choice
Hi, On Wed, 16 Jan 2008, Jan Beulich wrote: > 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? This is really a feature, try it with a visible option there which depends on a choice option. First for the choice type I think it's simpler to just look at the first choice option, anything more complex simply has to specify the type explicitly. The bigger problem is that menu_finalize() is little complex which makes such changes more difficult, basically it does two things (updating the dependencies and generating the menu structure) in one pass and it depends on a specific order, which is nonobvious. I really should clean this up to make it easier to follow what's happening. For now this means the dependency to the choice symbol has to be added a little later right before the call to menu_add_symbol(). bye, Roman -- 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/
Re: non-choice related config entries within choice
On Wed, Jan 16, 2008 at 01:46:57PM +, Jan Beulich wrote: > >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 The problem is that the two source happens in different places as they are part of a menu structure. So the Kconfig files cannot easily be refactored to use a sinlge source per file. 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/
Re: non-choice related config entries within choice
>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/
Re: non-choice related config entries within choice
On Wed, Jan 16, 2008 at 11:18:38AM +, 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/
non-choice related config entries within choice
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? Thanks, 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/
