linux-kernel - Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC

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, 14 Oct 2020 10:34:21 +0200
From:   Udo van den Heuvel <udovdh@...all.nl>
To:     Pavel Machek <pavel@....cz>
Cc:     Takashi Iwai <tiwai@...e.de>, Randy Dunlap <rdunlap@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-leds@...r.kernel.org, Dan Murphy <dmurphy@...com>,
        moderated for non-subscribers <alsa-devel@...a-project.org>
Subject: Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

On 14-10-2020 10:27, Pavel Machek wrote:
>> One should have thought about stuff beforehand.
> 
> We did. And decided this is best solution.

Then the thought process went awry.

>> The non-selectability is not my fault.
> 
> It also does not affect you in any way.

It does.
/boot fills up even sooner thanks to this unused code.
Compiles last longer because of this unused code.

> Feel free to go to the mic LED discussion to see why we did it like
> this. Then you can come up with better solution for problem at hand.

I did not think of forcing code onto somebody. Someone else did.
This is effectively the effect of the LEDs thing.

So why should I `fix` this when a Kconfig thing is considered 'expensive'?
If reasonable arguments fall to the floor then where do you go?

This is the same as some useless things in Fedora that one cannot simply
 uninstall.

Udo