linux-kernel - Re: [PATCH 1/4] kconfig: introduce the "imply" keyword

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: <44f95579-6c35-7592-08e3-d8dbb13026b2@solarflare.com>
Date:   Thu, 20 Oct 2016 15:52:04 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Richard Cochran <richardcochran@...il.com>,
        "Yann E MORIN" <yann.morin.1998@...e.fr>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Josh Triplett <josh@...htriplett.org>,
        <netdev@...r.kernel.org>, <linux-kbuild@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] kconfig: introduce the "imply" keyword

On 20/10/16 00:42, Nicolas Pitre wrote:
> diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
> index 069fcb3eef..c96127f648 100644
> --- a/Documentation/kbuild/kconfig-language.txt
> +++ b/Documentation/kbuild/kconfig-language.txt
> @@ -113,6 +113,33 @@ applicable everywhere (see syntax).
>  	That will limit the usefulness but on the other hand avoid
>  	the illegal configurations all over.
>  
> +- weak reverse dependencies: "imply" <symbol> ["if" <expr>]
> +  This is similar to "select" as it enforces a lower limit on another
> +  symbol except that the "implied" config symbol's value may still be
> +  set to n from a direct dependency or with a visible prompt.
> +  Given the following example:
> +
> +  config FOO
> +	tristate
> +	imply BAZ
> +
> +  config BAZ
> +	tristate
> +	depends on BAr
> +
> +  The following values are possible:
> +
> +	FOO		BAR		BAR's default	choice for BAZ
Should the third column not be "BAZ's default"?
> +	---------------	---------------	---------------	--------------
> +	n		y		n		N/m/y
> +	m		y		m		M/y/n
> +	y		y		y		Y/n
> +	y		n		*		N
Also, I don't think having any FOO=y should preclude BAZ=m.  Suppose both
FOO and FOO2 imply BAZ, FOO=y and FOO2=m.  Then if BAZ-features are only
desired for driver FOO2, BAz=m makes sense.
There is also the case of drivers with the ability to detect at runtime
whether BAZ is present, rather than making the decision at build time, but
I'm not sure how common that is.

-Ed