kconfig - a suggestion how to fix the select issue

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

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")

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

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.

Lets try to agree on the semantics with bools first please. When we have that in place lets extend it to modular - OK?

Sam

*shudder*

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?

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

So let me explain it with some other words:
B is visible because A=m
C is visible because B is visible.
Simple.

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

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.

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.

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.

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

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

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.

Which is exactly why I try to involve you in the discussion of a potential solution.

Sam

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

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?

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

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

Sam,

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.

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.

Thanks.
____

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.

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

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.

Sam Ravnborg wrote:
[Snipped]

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
[email protected]                 |                      -- Mark Twain
(905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
bridge: (877) 385-4099 code: 506 9191#

David Collier-Brown @ Sun, May 04, 2008 at 08:55:12AM -0400:
[]

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

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

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.

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

And beside that nothing stops us from verifying the dependencies of the options after select is applied and refusing to save the (broken) config.

Gruss
Bernd

[...]

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.

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.
____