linux-kernel - Re: [RFC 0/6] Regressions for "imply" behavior change

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:   Fri, 10 Apr 2020 09:26:38 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "jani.nikula@...ux.intel.com" <jani.nikula@...ux.intel.com>,
        "jgg@...pe.ca" <jgg@...pe.ca>, "arnd@...db.de" <arnd@...db.de>,
        "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "leon@...nel.org" <leon@...nel.org>,
        "Laurent.pinchart@...asonboard.com" 
        <Laurent.pinchart@...asonboard.com>,
        "kieran.bingham+renesas@...asonboard.com" 
        <kieran.bingham+renesas@...asonboard.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "nico@...xnic.net" <nico@...xnic.net>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "a.hajda@...sung.com" <a.hajda@...sung.com>,
        "jonas@...boo.se" <jonas@...boo.se>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "jernej.skrabec@...l.net" <jernej.skrabec@...l.net>
Subject: Re: [RFC 0/6] Regressions for "imply" behavior change

Hi Saeed,

On Fri, Apr 10, 2020 at 4:41 AM Saeed Mahameed <saeedm@...lanox.com> wrote:
> On Thu, 2020-04-09 at 11:41 +0300, Jani Nikula wrote:
> > For example, you have two graphics drivers, one builtin and another
> > module. Then you have backlight as a module. Using IS_REACHABLE(),
> > backlight would work in one driver, but not the other. I'm sure there
> > is
> > the oddball person who finds this desirable, but the overwhelming
> > majority would just make the deps such that either you make all of
> > them
> > modules, or also require backlight to be builtin.
>
> the previous imply semantics handled this by forcing backlight to be
> built-in, which worked nicely.

Which may have worked fine for backlight, but not for other symbols
with dependencies that are not always met.

=> Use "select" to enable something unconditionally, but this can only
    be used if the target's dependencies are met.
=> Use "imply" to enable an optional feature conditionally.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds