LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: LED naming standard for LED class
Date: Tue, 18 Mar 2008 00:35:01 -0300	[thread overview]
Message-ID: <20080318033501.GA17147@khazad-dum.debian.net> (raw)
In-Reply-To: <1205747515.4552.15.camel@dax.rpnet.com>

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

  reply	other threads:[~2008-03-18  3:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 10:35 [GIT PULL] LED updates Richard Purdie
2008-02-07 21:38 ` Henrique de Moraes Holschuh
2008-02-07 22:13   ` Richard Purdie
2008-02-07 23:23     ` [PATCH] leds: disable triggers on brightness set Henrique de Moraes Holschuh
2008-02-10 11:52       ` Németh Márton
2008-02-17 23:30         ` Richard Purdie
2008-02-18  1:59           ` Henrique de Moraes Holschuh
2008-02-08  7:03     ` [GIT PULL] LED updates Németh Márton
2008-02-08 11:20       ` Henrique de Moraes Holschuh
2008-02-10 11:52         ` Németh Márton
2008-03-16 18:18     ` Henrique de Moraes Holschuh
2008-03-16 19:29       ` Richard Purdie
2008-03-16 19:48         ` Henrique de Moraes Holschuh
2008-03-17  3:34           ` LED naming standard for LED class Henrique de Moraes Holschuh
2008-03-17  9:51             ` Richard Purdie
2008-03-18  3:35               ` Henrique de Moraes Holschuh [this message]
2008-03-18  4:55                 ` Henrique de Moraes Holschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080318033501.GA17147@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    --subject='Re: LED naming standard for LED class' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).