linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 May 2008 12:38:48 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kconfig - a suggestion how to fix the select issue

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
--
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/