non-choice related config entries within choice

non-choice related config entries within choice

[Jan Beulich]

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

Re: non-choice related config entries within choice

[Sam Ravnborg]

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

Re: non-choice related config entries within choice

[Jan Beulich]

>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

Re: non-choice related config entries within choice

[Sam Ravnborg]

On Wed, Jan 16, 2008 at 01:46:57PM +0000, 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

Re: non-choice related config entries within choice

[Roman Zippel]

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

Re: non-choice related config entries within choice

[Roman Zippel]

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