linux-kernel - Re: [PATCH v2] mux: remove the Kconfig question for the subsystem

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:   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