kconfig - a suggestion how to fix the select issue

kconfig - a suggestion how to fix the select issue

[Sam Ravnborg]

Today we have two ways to express/solve dependencies.

Top-down we have "depends on"
and bottom up we have "select".

The "depends on" dependencies at the same
time impact the visibility of a symbol.
A symbol with "depends on" not satisfied are not
visible and thus not shown in menuconfig.

The "select" method is a way to forcefully
set the selected symbol to the same value
as the one where the select are stated.

But this has shortcoming in relation to the
interface we like to present to the user.

Consider following example:

config A
	bool "a"

config B
	bool "b"
	depends on A

config C
	bool "c"
	depends on B

To be able to chose 'C' I have to chose
A and then B before I am even offered 
the possibility to chose 'C'.
And this is often less than obvious. C could
be a device that uses either USB or firewire
and I could not care less.

The usual way to solve this is to introduce
use of select like this:

config A
	bool "a"

config B
	bool "b"
	depends on A

config C
	bool "c"
	select B     <= use of select

With this change we have increased visibility
of C so it is shown in menuconfig.
But if we chose 'C' then we implicitly set
B='y' too but ignore the dependency of 'A' so
we end up with a configuration where:
A='n'
B='y'
C='y'
which is not what we wanted. As B depends on A we should
never see B equals 'y' when A equals 'n'.

The solution is not to let "select follow dependencies"
as the dependency on B could be complex (A || FOO).
Because we would not know if we should enable A or FOO.

So we need some other way to say the C require B.

The suggestion is to introduce a "require" term used
like this:

config A
        bool "a"

config B
        bool "b"
        depends on A

config C
        bool "c"
        require B

The require dependency will have impact on visibility.
C shall only be visible if all symbols it require are
visible. Note that visible does not imply 'chosen'.
In this case C would be visible when A is chosen.

When the user then choose C and B is not chosen 
then the user is prompted to choose B.

So user has to chose B in order to have C chosen.

This would make it visible for the user that choosing
a camera had the side-effect that USB had to be enabled too.
But if we have some general option that prevents the
visibility of USB we would not be offered the camara
in the first place

Comments?

	Sam

Re: kconfig - a suggestion how to fix the select issue

[Adrian Bunk]

On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
>...
> 
> config A
>         bool "a"
> 
> config B
>         bool "b"
>         depends on A
> 
> config C
>         bool "c"
>         require B
> 
> The require dependency will have impact on visibility.
> C shall only be visible if all symbols it require are
> visible. Note that visible does not imply 'chosen'.
> In this case C would be visible when A is chosen.
> 
> When the user then choose C and B is not chosen 
> then the user is prompted to choose B.
> 
> So user has to chose B in order to have C chosen.
>...
> Comments?


Given:

config A
	tristate "a"

config B
	tristate "b"
	depends on A

config C
	bool "c"
	require B

CONFIG_A=m


Will C be visible?


The underlying problem is that we use bool for two different cases:
- non-modular driver (answer would be "no")
- enable feature in driver (answer would be "depends on the value of D")


> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kconfig - a suggestion how to fix the select issue

[Sam Ravnborg]

On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> >...
> > 
> > config A
> >         bool "a"
> > 
> > config B
> >         bool "b"
> >         depends on A
> > 
> > config C
> >         bool "c"
> >         require B
> > 
> > The require dependency will have impact on visibility.
> > C shall only be visible if all symbols it require are
> > visible. Note that visible does not imply 'chosen'.
> > In this case C would be visible when A is chosen.
> > 
> > When the user then choose C and B is not chosen 
> > then the user is prompted to choose B.
> > 
> > So user has to chose B in order to have C chosen.
> >...
> > Comments?
> 
> 
> Given:
> 
> config A
> 	tristate "a"
> 
> config B
> 	tristate "b"
> 	depends on A
> 
> config C
> 	bool "c"
> 	require B
> 
> CONFIG_A=m
> 
> 
> Will C be visible?
If you followed my description then you would see
that the visibility of C are determineded by the dependencies
of C (none in this case) and the dependencies of the symbol
it requires. In this case B. B dpens on A and A equals m so B is
visible thus C is visible.

 
> The underlying problem is that we use bool for two different cases:
> - non-modular driver (answer would be "no")
> - enable feature in driver (answer would be "depends on the value of D")
Lets try to agree on the semantics with bools first please.
When we have that in place lets extend it to modular - OK?

	Sam

Re: kconfig - a suggestion how to fix the select issue

[Adrian Bunk]

On Sun, May 04, 2008 at 10:27:32AM +0200, Sam Ravnborg wrote:
> On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> > On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> > >...
> > > 
> > > config A
> > >         bool "a"
> > > 
> > > config B
> > >         bool "b"
> > >         depends on A
> > > 
> > > config C
> > >         bool "c"
> > >         require B
> > > 
> > > The require dependency will have impact on visibility.
> > > C shall only be visible if all symbols it require are
> > > visible. Note that visible does not imply 'chosen'.
> > > In this case C would be visible when A is chosen.
> > > 
> > > When the user then choose C and B is not chosen 
> > > then the user is prompted to choose B.
> > > 
> > > So user has to chose B in order to have C chosen.
> > >...
> > > Comments?
> > 
> > 
> > Given:
> > 
> > config A
> > 	tristate "a"
> > 
> > config B
> > 	tristate "b"
> > 	depends on A
> > 
> > config C
> > 	bool "c"
> > 	require B
> > 
> > CONFIG_A=m
> > 
> > 
> > Will C be visible?
> If you followed my description then you would see
> that the visibility of C are determineded by the dependencies
> of C (none in this case) and the dependencies of the symbol
> it requires. In this case B. B dpens on A and A equals m so B is
> visible thus C is visible.

*shudder*

> > The underlying problem is that we use bool for two different cases:
> > - non-modular driver (answer would be "no")
> > - enable feature in driver (answer would be "depends on the value of D")
> Lets try to agree on the semantics with bools first please.
> When we have that in place lets extend it to modular - OK?

I doubt the "extension" works this way since most of the interesting 
cases are with tristates.

But OK, here's some fun with bools:

config X86
	def_bool y

config A
	bool "a"

config B
	bool "b"
	depends on A

config D
	bool "d"
	depends on !B if X86

config E
	bool "e"

config C
	bool "c"
	depends on D || E
	requires B

Given:
- CONFIG_A=y
- CONFIG_B=n
- CONFIG_D=y
- CONFIG_E=n

Will C be visible?

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kconfig - a suggestion how to fix the select issue

[Sam Ravnborg]

On Sun, May 04, 2008 at 12:04:29PM +0300, Adrian Bunk wrote:
> On Sun, May 04, 2008 at 10:27:32AM +0200, Sam Ravnborg wrote:
> > On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> > > On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> > > >...
> > > > 
> > > > config A
> > > >         bool "a"
> > > > 
> > > > config B
> > > >         bool "b"
> > > >         depends on A
> > > > 
> > > > config C
> > > >         bool "c"
> > > >         require B
> > > > 
> > > > The require dependency will have impact on visibility.
> > > > C shall only be visible if all symbols it require are
> > > > visible. Note that visible does not imply 'chosen'.
> > > > In this case C would be visible when A is chosen.
> > > > 
> > > > When the user then choose C and B is not chosen 
> > > > then the user is prompted to choose B.
> > > > 
> > > > So user has to chose B in order to have C chosen.
> > > >...
> > > > Comments?
> > > 
> > > 
> > > Given:
> > > 
> > > config A
> > > 	tristate "a"
> > > 
> > > config B
> > > 	tristate "b"
> > > 	depends on A
> > > 
> > > config C
> > > 	bool "c"
> > > 	require B
> > > 
> > > CONFIG_A=m
> > > 
> > > 
> > > Will C be visible?
> > If you followed my description then you would see
> > that the visibility of C are determineded by the dependencies
> > of C (none in this case) and the dependencies of the symbol
> > it requires. In this case B. B dpens on A and A equals m so B is
> > visible thus C is visible.
> 
> *shudder*
So let me explain it with some other words:
B is visible because A=m
C is visible because B is visible.
Simple.

> 
> > > The underlying problem is that we use bool for two different cases:
> > > - non-modular driver (answer would be "no")
> > > - enable feature in driver (answer would be "depends on the value of D")
> > Lets try to agree on the semantics with bools first please.
> > When we have that in place lets extend it to modular - OK?
> 
> I doubt the "extension" works this way since most of the interesting 
> cases are with tristates.
> 
> But OK, here's some fun with bools:
> 
> config X86
> 	def_bool y
> 
> config A
> 	bool "a"
> 
> config B
> 	bool "b"
> 	depends on A
> 
> config D
> 	bool "d"
> 	depends on !B if X86
> 
> config E
> 	bool "e"
> 
> config C
> 	bool "c"
> 	depends on D || E
> 	requires B
> 
> Given:
> - CONFIG_A=y
> - CONFIG_B=n
> - CONFIG_D=y
> - CONFIG_E=n
> 
> Will C be visible?
The above has a syntax error. A 'depends on' cannot have an
if caluse.
And I did not get your point either.

Are you trying to say that we cannot improve kconfig to better
express the dependencies or what is your point?

Puzzeled...

	Sam

Re: kconfig - a suggestion how to fix the select issue

[Adrian Bunk]

On Sun, May 04, 2008 at 12:38:48PM +0200, Sam Ravnborg wrote:
> On Sun, May 04, 2008 at 12:04:29PM +0300, Adrian Bunk wrote:
> > On Sun, May 04, 2008 at 10:27:32AM +0200, Sam Ravnborg wrote:
> > > On Sun, May 04, 2008 at 11:11:45AM +0300, Adrian Bunk wrote:
> > > > On Sun, May 04, 2008 at 09:10:41AM +0200, Sam Ravnborg wrote:
> > > > >...
> > > > > 
> > > > > config A
> > > > >         bool "a"
> > > > > 
> > > > > config B
> > > > >         bool "b"
> > > > >         depends on A
> > > > > 
> > > > > config C
> > > > >         bool "c"
> > > > >         require B
> > > > > 
> > > > > The require dependency will have impact on visibility.
> > > > > C shall only be visible if all symbols it require are
> > > > > visible. Note that visible does not imply 'chosen'.
> > > > > In this case C would be visible when A is chosen.
> > > > > 
> > > > > When the user then choose C and B is not chosen 
> > > > > then the user is prompted to choose B.
> > > > > 
> > > > > So user has to chose B in order to have C chosen.
> > > > >...
> > > > > Comments?
> > > > 
> > > > 
> > > > Given:
> > > > 
> > > > config A
> > > > 	tristate "a"
> > > > 
> > > > config B
> > > > 	tristate "b"
> > > > 	depends on A
> > > > 
> > > > config C
> > > > 	bool "c"
> > > > 	require B
> > > > 
> > > > CONFIG_A=m
> > > > 
> > > > 
> > > > Will C be visible?
> > > If you followed my description then you would see
> > > that the visibility of C are determineded by the dependencies
> > > of C (none in this case) and the dependencies of the symbol
> > > it requires. In this case B. B dpens on A and A equals m so B is
> > > visible thus C is visible.
> > 
> > *shudder*
> So let me explain it with some other words:
> B is visible because A=m
> C is visible because B is visible.
> Simple.

I understand what you are saying.

The problem is that with A=m, C=y built-in code enabled by C cannot 
access the code enabled by A which can result in a build error.

> > > > The underlying problem is that we use bool for two different cases:
> > > > - non-modular driver (answer would be "no")
> > > > - enable feature in driver (answer would be "depends on the value of D")
> > > Lets try to agree on the semantics with bools first please.
> > > When we have that in place lets extend it to modular - OK?
> > 
> > I doubt the "extension" works this way since most of the interesting 
> > cases are with tristates.
> > 
> > But OK, here's some fun with bools:
> > 
> > config X86
> > 	def_bool y
> > 
> > config A
> > 	bool "a"
> > 
> > config B
> > 	bool "b"
> > 	depends on A
> > 
> > config D
> > 	bool "d"
> > 	depends on !B if X86
> > 
> > config E
> > 	bool "e"
> > 
> > config C
> > 	bool "c"
> > 	depends on D || E
> > 	requires B
> > 
> > Given:
> > - CONFIG_A=y
> > - CONFIG_B=n
> > - CONFIG_D=y
> > - CONFIG_E=n
> > 
> > Will C be visible?
> The above has a syntax error. A 'depends on' cannot have an
> if caluse.

I know I'm bad at the syntax when I'm not trying stuff myself.
	depends on !B || !X86
is the same and should be the correct syntax.

Or make it just
	depends on !B

The problem is not the syntax, the problem is whether C should be 
visible, and what happens if the user enables it.

> And I did not get your point either.
> 
> Are you trying to say that we cannot improve kconfig to better
> express the dependencies or what is your point?

My point is that all this "select follows depenencies" is easily said, 
but doing it in a way that it's better than what we have today is 
nontrivial.

I'm not even sure whether the best solution might be to do it manually 
like we are doing with SSB_POSSIBLE, but if I'd start to convert stuff 
to that I'm sure many maintainers will say "no, kconfig is broken" and 
even reject patches.

If you think I'm wrong implement your suggestion and then handle all the 
cornercases. It might or might not work. I'm just saying that it isn't 
an easy problem.

> Puzzeled...
> 
> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kconfig - a suggestion how to fix the select issue

[Sam Ravnborg]

> > > > > 
> > > > > config A
> > > > > 	tristate "a"
> > > > > 
> > > > > config B
> > > > > 	tristate "b"
> > > > > 	depends on A
> > > > > 
> > > > > config C
> > > > > 	bool "c"
> > > > > 	require B
> > > > > 
> > > > > CONFIG_A=m
> > > > > 
> > > > > 
> > > > > Will C be visible?
> > > > If you followed my description then you would see
> > > > that the visibility of C are determineded by the dependencies
> > > > of C (none in this case) and the dependencies of the symbol
> > > > it requires. In this case B. B dpens on A and A equals m so B is
> > > > visible thus C is visible.
> > > 
> > > *shudder*
> > So let me explain it with some other words:
> > B is visible because A=m
> > C is visible because B is visible.
> > Simple.
> 
> I understand what you are saying.
> 
> The problem is that with A=m, C=y built-in code enabled by C cannot 
> access the code enabled by A which can result in a build error.

That is a different type of issue which would most likely
be solved by a "depends on A == y"

> > > But OK, here's some fun with bools:
> > > 
> > > config X86
> > > 	def_bool y
> > > 
> > > config A
> > > 	bool "a"
> > > 
> > > config B
> > > 	bool "b"
> > > 	depends on A
> > > 
> > > config D
> > > 	bool "d"
> > > 	depends on !B if X86
> > > 
> > > config E
> > > 	bool "e"
> > > 
> > > config C
> > > 	bool "c"
> > > 	depends on D || E
> > > 	requires B
> > > 
> > > Given:
> > > - CONFIG_A=y
> > > - CONFIG_B=n
> > > - CONFIG_D=y
> > > - CONFIG_E=n
> > > 
> > > Will C be visible?
> > The above has a syntax error. A 'depends on' cannot have an
> > if caluse.
> 
> I know I'm bad at the syntax when I'm not trying stuff myself.
> 	depends on !B || !X86
> is the same and should be the correct syntax.
> 
> Or make it just
> 	depends on !B
> 
> The problem is not the syntax, the problem is whether C should be 
> visible, and what happens if the user enables it.
OK - lets analyse this.
B is visible (because A is y)
D is visible (because B is n)
E is visible

So per the definition C is visible.
If user choose 'C' then user will be prompted to choose B
due to the "require B".
User now set B equal to 'y' and we have following situation:
B is visible (because A is y)
D is invisible (because B is y)
E is visible
So per definiton C is still visible.
So user is now prompted to chose C.


On the other hand had we had a:
config C
	bool "c"
	depends on D
	requires B

Then when user set B equal 'y' user no longer
are offered the possibility to chose 'C' as it is no
longer visible.

> > 
> > Are you trying to say that we cannot improve kconfig to better
> > express the dependencies or what is your point?
> 
> My point is that all this "select follows depenencies" is easily said, 
> but doing it in a way that it's better than what we have today is 
> nontrivial.
Which is exactly why I try to involve you in the discussion
of a potential solution.

	Sam

Re: kconfig - a suggestion how to fix the select issue

[Adrian Bunk]

On Sun, May 04, 2008 at 02:17:47PM +0200, Sam Ravnborg wrote:
> > > > > > 
> > > > > > config A
> > > > > > 	tristate "a"
> > > > > > 
> > > > > > config B
> > > > > > 	tristate "b"
> > > > > > 	depends on A
> > > > > > 
> > > > > > config C
> > > > > > 	bool "c"
> > > > > > 	require B
> > > > > > 
> > > > > > CONFIG_A=m
> > > > > > 
> > > > > > 
> > > > > > Will C be visible?
> > > > > If you followed my description then you would see
> > > > > that the visibility of C are determineded by the dependencies
> > > > > of C (none in this case) and the dependencies of the symbol
> > > > > it requires. In this case B. B dpens on A and A equals m so B is
> > > > > visible thus C is visible.
> > > > 
> > > > *shudder*
> > > So let me explain it with some other words:
> > > B is visible because A=m
> > > C is visible because B is visible.
> > > Simple.
> > 
> > I understand what you are saying.
> > 
> > The problem is that with A=m, C=y built-in code enabled by C cannot 
> > access the code enabled by A which can result in a build error.
> 
> That is a different type of issue which would most likely
> be solved by a "depends on A == y"

So feature C in driver B won't be enabled in allmodconfig or 
distribution kernels?

> > > > But OK, here's some fun with bools:
> > > > 
> > > > config X86
> > > > 	def_bool y
> > > > 
> > > > config A
> > > > 	bool "a"
> > > > 
> > > > config B
> > > > 	bool "b"
> > > > 	depends on A
> > > > 
> > > > config D
> > > > 	bool "d"
> > > > 	depends on !B if X86
> > > > 
> > > > config E
> > > > 	bool "e"
> > > > 
> > > > config C
> > > > 	bool "c"
> > > > 	depends on D || E
> > > > 	requires B
> > > > 
> > > > Given:
> > > > - CONFIG_A=y
> > > > - CONFIG_B=n
> > > > - CONFIG_D=y
> > > > - CONFIG_E=n
> > > > 
> > > > Will C be visible?
> > > The above has a syntax error. A 'depends on' cannot have an
> > > if caluse.
> > 
> > I know I'm bad at the syntax when I'm not trying stuff myself.
> > 	depends on !B || !X86
> > is the same and should be the correct syntax.
> > 
> > Or make it just
> > 	depends on !B
> > 
> > The problem is not the syntax, the problem is whether C should be 
> > visible, and what happens if the user enables it.
> OK - lets analyse this.
> B is visible (because A is y)
> D is visible (because B is n)
> E is visible
> 
> So per the definition C is visible.
> If user choose 'C' then user will be prompted to choose B
> due to the "require B".
> User now set B equal to 'y' and we have following situation:
> B is visible (because A is y)
> D is invisible (because B is y)
> E is visible
> So per definiton C is still visible.
> So user is now prompted to chose C.
> 
> 
> On the other hand had we had a:
> config C
> 	bool "c"
> 	depends on D
> 	requires B
> 
> Then when user set B equal 'y' user no longer
> are offered the possibility to chose 'C' as it is no
> longer visible.

Do you want in this case show the user the option C that can never be
enabled on this architecture or do you want to implement logic that can
prove whether any combination of values exists that allows C to be 
enabled?

> > > Are you trying to say that we cannot improve kconfig to better
> > > express the dependencies or what is your point?
> > 
> > My point is that all this "select follows depenencies" is easily said, 
> > but doing it in a way that it's better than what we have today is 
> > nontrivial.
> Which is exactly why I try to involve you in the discussion
> of a potential solution.

And pointing you at the possible problems is exactly what I'm doing.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: kconfig - a suggestion how to fix the select issue

[Oleg Verych]

Sam,

> > Given:
> > - CONFIG_A=y
> > - CONFIG_B=n
> > - CONFIG_D=y
> > - CONFIG_E=n
> > 
> > Will C be visible?
> The above has a syntax error. A 'depends on' cannot have an
> if caluse.

would you please write logic rules with more neutral language, like

(A || B) && C

or similar. Depencies (forward or backward) can be described as

SYM_FOO <- { # depencies/value

  ($SYM_DEP1 || !$SYM_DEP2) && $SYM_DEP3=xx
  # implicit or
  $SYM_DEP4 || $SYM_DEP5

} -> { # selects

  SYM_2SELECT1 = $SYM_BAR ? foo_bar : bar_for
  SYM_2SELECT2 = bar; SYM_BA; SYM_ZZ

# SYM_BA && SYM_ZZ will have value of SYM_FOO
}

or something.

> And I did not get your point either.

I try to design TUI now for better multidimensional walking/selecting on
the web of symbols and decencies, and i don't get those kconfig
constructs.

> Are you trying to say that we cannot improve kconfig to better
> express the dependencies or what is your point?
> 
> Puzzeled...

Thanks.
____

Re: kconfig - a suggestion how to fix the select issue

[Bernd Petrovitsch]

On Sun, 2008-05-04 at 09:10 +0200, Sam Ravnborg wrote:
> Today we have two ways to express/solve dependencies.
> 
> Top-down we have "depends on"
> and bottom up we have "select".
> 
> The "depends on" dependencies at the same
> time impact the visibility of a symbol.
> A symbol with "depends on" not satisfied are not
> visible and thus not shown in menuconfig.

Perhaps this is problem: The menu item shouldn't be selectable for sure
but it may well be visible (and I'm purposely ignoring details of "how
to grey out" for the different user interfaces).
If it's visible (but not selectable) the user interface can provide the
auto-generated requirements (derived from the "depends on" chains) as
part of the "help" or where ever it seems useful. And the user at least
knows where to look further.

> The "select" method is a way to forcefully
> set the selected symbol to the same value
> as the one where the select are stated.

Which makes sense from the usability point of view for typical library
functions (e.g. zlib, CRC, ...).
But that ("which CONFIG_ variables actually selected this CONFIG_
variable" and/or "which CONFIG_ variables will selected this CONFIG_
variable") could also be automatically generated and displayed.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: kconfig - a suggestion how to fix the select issue

[Matthias Schniedermeyer]

On 04.05.2008 12:12, Bernd Petrovitsch wrote:
> On Sun, 2008-05-04 at 09:10 +0200, Sam Ravnborg wrote:
> > Today we have two ways to express/solve dependencies.
> > 
> > Top-down we have "depends on"
> > and bottom up we have "select".
> > 
> > The "depends on" dependencies at the same
> > time impact the visibility of a symbol.
> > A symbol with "depends on" not satisfied are not
> > visible and thus not shown in menuconfig.
> 
> Perhaps this is problem: The menu item shouldn't be selectable for sure
> but it may well be visible (and I'm purposely ignoring details of "how
> to grey out" for the different user interfaces).
> If it's visible (but not selectable) the user interface can provide the
> auto-generated requirements (derived from the "depends on" chains) as
> part of the "help" or where ever it seems useful. And the user at least
> knows where to look further.

I always wondered why there is no "grey out", at least optionaly.

My "favourite"(tm) example of a sub-marine is: Wireless drivers (mac80211).

The config-option to switch on the visibility of the mac80211 drivers 
("CONFIG_MAC80211") is conveniently located on the other side of the 
milky way.
(3 menus down, a sitestep and 2 up again. At least in menuconfig)







Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: kconfig - a suggestion how to fix the select issue

[David Collier-Brown]

Sam Ravnborg wrote:
[Snipped]
> The suggestion is to introduce a "require" term used
> like this:
> 
> config A
>         bool "a"
> 
> config B
>         bool "b"
>         depends on A
> 
> config C
>         bool "c"
>         require B
> 
> The require dependency will have impact on visibility.
> C shall only be visible if all symbols it require are
> visible. Note that visible does not imply 'chosen'.
> In this case C would be visible when A is chosen.
> 
> When the user then choose C and B is not chosen 
> then the user is prompted to choose B.
> 
> So user has to chose B in order to have C chosen.
> 
> This would make it visible for the user that choosing
> a camera had the side-effect that USB had to be enabled too.
> But if we have some general option that prevents the
> visibility of USB we would not be offered the camara
> in the first place

In the example you suggest, the user would not see the
option of choosing the camera at C unless they selected
USB at A, and would wonder where the camera disappeared
to...

I speculate that having two ways to express a dependency,
and the addtition of visibility control makes the
dependency tree-walk into a problem which is no longer
solvable in trivial logic. That in turn makes my head 
explode (;-))

I wonder if one could simplify back into a flat set of
selections without visibility rules and a backwards-
chaining "you need to select these too" message emitter,
and if that would be worthwhile.

--dave (who used to do formal logics) c-b
-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb@sun.com                 |                      -- Mark Twain
(905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
bridge: (877) 385-4099 code: 506 9191#

Re: kconfig - a suggestion how to fix the select issue

[Oleg Verych]

David Collier-Brown @ Sun, May 04, 2008 at 08:55:12AM -0400:
[]
> I speculate that having two ways to express a dependency,
> and the addtition of visibility control makes the
> dependency tree-walk into a problem which is no longer
> solvable in trivial logic. That in turn makes my head
> explode (;-))

In short:
mixing all together and applying resolving and UI heuristics on top.

> I wonder if one could simplify back into a flat set of
> selections without visibility rules and a backwards-
> chaining "you need to select these too" message emitter,
> and if that would be worthwhile.

No need to hide anything and invent complexity. Flexible and
human-friendly interface. (Batch things like def_condig are done by
humans, randconfig -- useless if there's no heuristics, allyes - simple.)

Just UI part for now. Automation of selection can be applied only, after
one can see whole picture. Say, you have [ UCcamers ] which depends on
USB, Video, etc.

+-- Navigation ---------------------------------------------------+
|  ...            [ arch     ]      [ atm ]     [ w-less speaker] |
|  [ kernel ] --> [ drivers  ]  --> [ fun ] --> [ camerass      ] |
|  [ klibc  ]     [ file sys ]      [ mtd ]     [ manual DMA    ] |
|  ...            ...               ...         ...               |
+-----------------------------------------------------------------+
+--     needs     ------+  +-- configure -----+  +--  options  ---+
| ++Universal S bus++++ |  |  ...             |  | build: y [m] n |
| --Video capture---    |<-+-[* UCcamera    ]-+->| RGB support y  |
| --sysfs kernel for u- |  |  * LPTcamera     |  | YUV support y  |
|                       |  |  * RS232camera   |  | HSB support y  |
+-----------------------+  +------------------+  +----------------+
+-- command line/text editor -- olecom@kit[configure] ------------+
$ build = m \n
$ go <

+--  walk tags  ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | USB camera with foo bar features     |
| fun, [camerass]        | | with dual-core toaster and coffee    |
|                        | | machine inside                       |
|                        | |                                      |
|                        | | Options:                             |
|                        | | * RGB enables RGB                    |
|                        | | ....                                 |
+------------------------+ +--------------------------------------+

So, after 'go <' command (visually or command-lineually) we will be in
[--Video capture--] which isn't configured/enabled yet (due to --)

Now,

+-- Navigation ---------------------------------------------------+
|  ...            [ arch     ]      [ atm ]     [ w-less speaker] |
|  [ kernel ] --> [ drivers  ]  --> [*fun*] --> [ camerass      ] |
|  [ klibc  ]     [ file sys ]      [ mtd ]     [ manual DMA    ] |
|  ...            ...               ...         ...               |
+-----------------------------------------------------------------+
+--     needs     ------+  +-- configure -----+  +--  options  ---+
| ++Universal S bus++++ |  |  ...             |  | build: y [m] n |
| [-Video capture--]    |<-+-[* UCcamera    ]-+->| RGB support y  |
| --sysfs kernel for u- |  |  * LPTcamera     |  | YUV support y  |
|                       |  |  * RS232camera   |  | HSB support y  |
+-----------------------+  +------------------+  +----------------+
+-- command line/text editor -- olecom@kit[ needs   ] ------------+
$ build = m \n
$ go < \n
$ we are here, hitting enter on needs/video
+--  walk tags  ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | Video processing for everyone        |
| fun, cameras, [videoP] | | all is supported all works with no   |
|                        | | OOP and shaman drums                 |
|                        | |                                      |
|                        | | Inside MMA:                          |
|                        | | * conf: DEBUG                        |
|                        | | * build: chip1...                    |
+------------------------+ +--------------------------------------+

we will have:

+-- Navigation ---------------------------------------------------+
|  [ arch     ]    [ mtd   ]    [ radio ]    [ bt8xx    ]         |
|  [ drivers  ] -> [ media ] -> [*video*] -> [ cpia2    ]         |
|  [ file sys ]    [ ps3   ]    [ common]    [ usbvideo ]         |
|  ...            ...               ...         ...               |
+-----------------------------------------------------------------+
+--     needs     ------+  +-- configure -----+  +--  options  ---+
| --V4L1--              |  |  ...             |  | menu:          |
| --V4L2--              |<-+-[*Video capture]-+->| * DEBUG_FOO    |
| --V4W7--              |  |  * Video decode  |  | * bt8xx        |
|                       |  |  * Video improve |  | ...            |
+-----------------------+  +------------------+  +----------------+
+-- command line/text editor -- olecom@kit[configure] ------------+
$ go < \n
$ we are here, hitting enter on needs/video
$
+--  walk tags  ---------+ +------------- Description ------------+
| intro, kernel, drivers,| | Video processing for everyone        |
| fun, cameras, [video]  | | all is supported all works with no   |
|                        | | OOP and shaman drums                 |
|                        | |                                      |
|                        | | Inside MMA:                          |
|                        | | * this is menu                       |
|                        | |                                      |
+------------------------+ +--------------------------------------+

== [ rant ] ==

Can some of those PS3 or KDE teams design proper "Konfigure Linux"
game for kernel hackers? I try to do this with TERM=linux, `sh`, and
`sed`. Patching paper work isn't for such tasks.

On collecting CONFIG_ info by gcc in sources, thus generating symbol
dependency automatically, was told to shut up. Let's see what will
happen next. Don't forget to use cultural skills, imagination and
creativity.
--
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M

Re: kconfig - a suggestion how to fix the select issue

[Rene Herman]

On 04-05-08 09:10, Sam Ravnborg wrote:

> Today we have two ways to express/solve dependencies.
> 
> Top-down we have "depends on"
> and bottom up we have "select".
> 
> The "depends on" dependencies at the same
> time impact the visibility of a symbol.
> A symbol with "depends on" not satisfied are not
> visible and thus not shown in menuconfig.

I've always really disliked the visibility thing. I believe it's not really 
the core issue here but regardless of anything else, could we not "grey out" 
non-selectable options with its helpt text still available? That's much more 
the standard UI paradigm.

Rene.

Re: kconfig - a suggestion how to fix the select issue

[Sam Ravnborg]

On Sun, May 04, 2008 at 09:28:54PM +0200, Rene Herman wrote:
> On 04-05-08 09:10, Sam Ravnborg wrote:
> 
> >Today we have two ways to express/solve dependencies.
> >
> >Top-down we have "depends on"
> >and bottom up we have "select".
> >
> >The "depends on" dependencies at the same
> >time impact the visibility of a symbol.
> >A symbol with "depends on" not satisfied are not
> >visible and thus not shown in menuconfig.
> 
> I've always really disliked the visibility thing. I believe it's not really 
> the core issue here but regardless of anything else, could we not "grey 
> out" non-selectable options with its helpt text still available? That's 
> much more the standard UI paradigm.

Works in xconfig - but last I tried I failed to enable it in menuconfig.
It should be doable I just failed to see how.

And as my linux time-share for this month is already almost consumed
I will not find time to look at it :-(

	Sam

Re: kconfig - a suggestion how to fix the select issue

[Jan Engelhardt]

On Sunday 2008-05-04 09:10, Sam Ravnborg wrote:

>Today we have two ways to express/solve dependencies.
>
>Top-down we have "depends on"
>and bottom up we have "select".
>
>The "depends on" dependencies at the same time impact the visibility of 
>a symbol. A symbol with "depends on" not satisfied are not visible and 
>thus not shown in menuconfig.
>
>The "select" method is a way to forcefully set the selected symbol to 
>the same value as the one where the select are stated.
>
>But this has shortcoming in relation to the interface we like to 
>present to the user.
[...]

Suggestion:

Make kconfig work like an interactive package manager. All objects are 
visible and the user can select any of them.

depends and selects are resolved upon request only, i.e. when the user 
hits Exit or manually initiates a resolve request. Kconfig then checks 
to see if all dependencies are satisfied, and if it cannot automatically 
solve it — because it encounters an alternation expression (a || foo) — 
it asks the user to select one.

If user input is not available, exit with error (much like `make 
oldconfig </dev/null` already does on new options.)

Drawback:

Most likely a lot of work.


Consider/Suggested syntax:

	menuconfig V4L2
		tristate "video and all that"
	
	if V4L2
	
	config MY_CAMERA
		tristate "nice cam"
		requires USB || FIREWIRE
	
	endif

leading to a new screen on dependency resolution (when USB=n && 
FIREWIRE=n), showing a modified "choice" prompt where you can 
either
1) change the state of CONFIG_MY_CAMERA to y/m/n.
2) select one of the required dependencies.

	CONFIG_MY_CAMERA has unsatisfied dependencies.

	<M> nice cam
	    ( ) USB
	    ( ) FireWire

Of course a bit of thinking on how to display things is needed for more 
complex requires.

Re: kconfig - a suggestion how to fix the select issue

[Oleg Verych]

>  Suggestion:
>
>  Make kconfig work like an interactive package manager. All objects are
>  visible and the user can select any of them.

It seems, like package maintainers leave all their job to end user. I don't know
many packages, which are as configurable as software package itself. To solve
few alternatives or versioning -- is kind of easy job: package is
built statically.
Otherwise they just pull all-new stuff anyway.

As of kernel config, there must be a simple and flexible tool to help
constructing
correct CONFIG_* sets as for developers to develop as for users to use.

Current situation is when "real guru edits with `cat >source.c`" is not funny.
____