linux-kernel - Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver

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:   Mon, 19 Oct 2020 16:28:15 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Ed W <lists@...dgooses.com>, Hans de Goede <hdegoede@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     fe@....tdt.de, "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform
 driver

On 13.10.20 23:46, Ed W wrote:

> The original naming was board specific. Then Enrico (not unreasonably - I actually prefer his
> naming) changed the naming to be non board specific. Then within 2 months PC Engines introduced ACPI
> based config using the old names.

Which "old names" are you referring to ?
The really old apuv1 led-only driver ?

> So if we are holding "userspace breakage" as the gold standard, then the original (also the current)
> names have actually been around longest and likely cause the least userspace breakage.

Exactly. Linus often stated "dont break userland" as a primary goal, and
that with really good reasons: the kernel is *the* hardware abstraction
layer. Having userland to deal with thousands of hardware details in
userland would cause extreme management complexity.

> Also, some other pieces of this module have already been removed (SIM Swap), so there is an existing
> precedent for "userspace breakage" and trimming down this platform driver.

Not quite. SIM swap hasn't been actually used in the field (at least as
far as I know). And we're planning to put it into different subsystem
(probably rfkill) anyways.

> In big picture terms, changing the name of the LED device doesn't seem a huge concern to me... A
> udev rule can setup compatibility forwards/backwards quite trivially I think?

Small kernel update causes existing applications to FAIL. Applications
now have to be changed to deal with *different* configuration, based on
factors like BIOS version.

We're dealing with embedded applications. There is no operator of these
boxes. Maybe some times an operator of the machinary comes around - and
needs to rely on the LEDs. Not as critial as an direction indicator in
a car, but still important.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287