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  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:   Tue, 5 Mar 2019 09:23:06 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Linus Walleij <linusw@...nel.org>,
        Enrico Weigelt <info@...ux.net>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] x86: apuv2: fix input dependencies

On Tue, Mar 5, 2019 at 1:18 AM Enrico Weigelt, metux IT consult
<lkml@...ux.net> wrote:
>
> On 04.03.19 21:19, Arnd Bergmann wrote:
>
> > This could be fixed using either a dependency or a 'select' statement.
> > I'm chosen 'depends on' here since it is simpler has a lower risk of
> > introducing circular dependencies.
>
> I'd rather prefer using 'select'.
>
> Otherwise the driver won't appear at all if INPUT or INPUT_KEYBOARD
> aren't enabled (eg. when you start w/ minimal config - which I do
> frequently), and people have a hard time actually finding/enabling it.

No, that wouldn't be good here. In effect that means that with INPUT disabled,
most of the x86 platform drivers are disabled, until you enable the
PCENGINES_APU2 symbol, which then ends up showing all the other
symbols at once, and changing them to their default states.

Another problem is that you likely run into circular dependency chains
after trying that. The best practice for select vs. depends are

1. try to use 'depends on' if you can
2. use 'select' on hidden symbols, but not user visible ones
3. for each symbol, use either 'depends on'  or 'select' from all other
    drivers that need it, and do it consistently
4. never select entire subsystems, only helper code.

Those are sometimes at odds. I used 'select' for the LEDS code
because of 3. and 4, even though that goes against 2. For INPUT,
there is no real debate though.

   Arnd

Powered by blists - more mailing lists