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: <a546f2db-371e-4d2f-a0ee-c71fcae8c548@app.fastmail.com>
Date:   Wed, 07 Dec 2022 09:41:50 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Randy Dunlap" <rdunlap@...radead.org>,
        "Peter Rosin" <peda@...ntia.se>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:     "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

On Tue, Dec 6, 2022, at 23:20, Randy Dunlap wrote:
> On 7/4/17 01:22, Peter Rosin wrote:
>> The MULTIPLEXER question in the Kconfig might be confusing and is
>> of dubious value. Remove it. This makes consumers responsible for
>> selecting MULTIPLEXER, which they already do.
>> 
>> Signed-off-by: Peter Rosin <peda@...ntia.se>
>
>
> How does a user enable any of the 4 drivers in drivers/mux/Kconfig unless
> some other totally unrelated driver has just happened to select MULTIPLEXER
> so that the mux driver menu is visible to them?

We have this mechanism for a few subsystems, LEDS_CLASS/NEW_LEDS and
CRYPTO being more common examples.

The idea clearly is that there is no need for the subsystem if no
drivers call into it. This works if every single driver calling
\(devm_\|\)mux_control_get also results in 'select MULTIPLEXER'
in Kconfig, and none of them ever uses 'depends on MULTIPLEXER'.
I think this is used correctly most of the time in mainline:
git grep '\<\(mux/consumer.h\|MULTIPLEXER\)\>' indicates that
PHY_J721E_WIZ and MTD_PHYSMAP_BT1_ROM may not actually need it,
but that is fairly harmless.

For the other subsystems I mentioned, there are occasionally 
problems with missing 'select' that tend to be a pain to find,
compared to subsystems consistently using 'depends on', which
show up as link failures in randconfig builds.

    Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ