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@xxxxxxxxx -- +49-151-27565287
