linux-kernel - Re: what does select statement mean in Kconfig file?

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] [day] [month] [year] [list]

Date:	Sun, 22 Jul 2007 00:00:55 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Krzysztof Halasa <khc@...waw.pl>
CC:	"Robert P. J. Day" <rpjday@...dspring.com>,
	jidong xiao <jidong.xiao@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: what does select statement mean in Kconfig file?

Krzysztof Halasa wrote:
> Stefan Richter <stefanr@...6.in-berlin.de> writes:
> 
>> The latter is sometimes hard or impossible to satisfy.  Therefore the
>> select statement should be used with care, i.e. only for library-type
>> helper code which itself shouldn't depend on further options.
> 
> How about depending on common dependency?
> 
> Something like
> 
> config A
> 	bool XXX
> 	depends on ARM
> 
> config B
> 	depends on ARM
> 	select A
> 
> 
> or:
> 
> if ARM
> 	config A
> 		bool XXX
> endif
> 
> if ARM
> 	config B
> 		select A
> endif

That's OK.  Or generally, if A depends on X and B wants to select A,
then it has to be guaranteed by whatever means that X is enabled,
because "make XYZconfig" cannot select recursively.  Duplicating A's
dependencies as dependencies for B is one way to ensure that A's
dependencies are satisfied when B selects A.  Another way is to select
not only A but also A's dependencies.

That's why I wrote "/shouldn't/ depend on further options" rather than
"/must not/ depend on further options".

But whatever you do, as soon as you add a "select A", you have to watch
if anybody eventually makes A dependent on something else.  Therefore
think twice before you use select.

Also, while select makes it easy for users to enable options, it makes
it somewhat difficult for users to /disable/ options.  So there are also
tradeoffs in usability.  This essentially means that you should never
select huge subsystems.  As I said, only library-like helpers are
suitable for select.
-- 
Stefan Richter
-=====-=-=== -=== =-=-=
http://arcgraph.de/sr/
-
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/