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 14:17:47 +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

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