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]

Message-ID: <20080504090429.GH5838@cs181133002.pp.htv.fi>
Date:	Sun, 4 May 2008 12:04:29 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Sam Ravnborg <sam@...nborg.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 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

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