netdev - 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]

Date:   Thu, 20 Oct 2016 08:38:21 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     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>,
        Thomas Gleixner <tglx@...utronix.de>, 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 Thu, Oct 20, 2016 at 03:52:04PM +0100, Edward Cree wrote:
> 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.

That's exactly the problem that motivated "imply" in the first place:
while that's *possible*, it means the user needs to know that they're
breaking BAZ support for driver FOO.

In theory, someone could extend the UI to note the symbols with an
"imply" for a given symbol and provide additional help for the implied
symbol that explains the implications.  In that case, it might make
sense to allow the user to explicitly mark a symbol as 'm', with
appropriate explanations of the implications.  But in the absence of
that, the simple solution seems like preventing 'm' for a symbol implied
by a symbol marked as 'y'.