linux-kernel - Re: LED naming standard for LED class

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:	Tue, 18 Mar 2008 00:35:01 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: LED naming standard for LED class

On Mon, 17 Mar 2008, Richard Purdie wrote:
> On Mon, 2008-03-17 at 00:34 -0300, Henrique de Moraes Holschuh wrote:
> > Richard, isn't there *any* way to change this new ABI?  It has not been in
> > any stable mainline release yet, so it is not too late if we do it now.
> 
> It is not an new ABI, its an extension as per the way it was documented
> to work.

It is a full ABI break for any drivers you change a LED name.  It is not
an ABI break for drivers which *add* new LEDs with the new names, but keep
the old naming on older leds.  And almost all of the changed drivers had a
stable release already.

There is no way we can pass a sysfs node name change like that as an
extension of the ABI, as it breaks all userspace scripts that used the old
node name.

Looking at the commit, the following drivers had ABI breaks to go
from "function" to "driver:color:function": nas100d, nslu2, wistron.
These can be considered bug-fixing, since "function" is clash-prone.

The following drivers had ABI breaks to add the middle ":" for the color
field: applesmc, ams-delta, net48, wrap, asus, b43.

The following drivers had ABI breaks to go from driver to
driver:color:function : corgi, locomo, spitz, tosa.

Looks like it was a hideous mess to me, and IMO we can pretty much say
that the naming guidelines were nothing but a dream before the commit.

Anyway, you did break ABI in 13 drivers, and only 3 could be considered a
bug fix.  And if you're going to break the ABI (I am *not* speaking
against it in this case), let's make the best of it, please.

> The problem is the "bad" ABI has existed in that form since somewhere
> around 2.6.15 and it is therefore too late to drop things from it or

LED drivers did whatever they wanted, no matter what docs said.  Each LED
driver had its own ABI, and only a few of those followed what was
described in the led class docs.

> rearrange it. The ABI described additions being allowed so we're taking
> advantage of that to gain something which should have really been there
> originally. Short term there is some complexity with some limits but
> they're going away so there is no problem.

Now that we have it clear that a widespread ABI break took place, the
above reasoning doesn't hold anymore, and there is no reason to fix the
"past mistake" in the led class documentation.

> The alternative is we throw the whole thing away and go to random
> numbers for the different LEDs and attributes. To work out which LED is
> which you then have to read up to 3 files per LED before you can even
> decide whether its the one you want. I don't like that idea...

I didn't suggest that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/