linux-kernel - kconfig - a suggestion how to fix the select issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 May 2008 09:10:41 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Roman Zippel <zippel@...ux-m68k.org>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/