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: LED naming standard for LED class
Date: Mon, 17 Mar 2008 00:34:58 -0300	[thread overview]
Message-ID: <20080317033458.GA20486@khazad-dum.debian.net> (raw)
In-Reply-To: <20080316194823.GA31782@khazad-dum.debian.net>

(changing the subject.  Newcomers, the context is given by commit
6c152beefbf90579d21afc4f7e075b1f801f9a75).

On Sun, 16 Mar 2008, Henrique de Moraes Holschuh wrote:
> On Sun, 16 Mar 2008, Richard Purdie wrote:
> > As I understand it 2.6.26 will lose the limitation on the name size
> > entirely so the problem will go away soon. I don't want to change the
> > existing ABI so changing to what you describe above isn't possible. You
> > could leave the devicename empty if you wish although I'd prefer you not
> > to. Keeping it short might be the best option for 2.6.25.
> 
> Hmm, that means I will have to keep the short names, since I can't very
> much have two different ABIs across several kernel versions... or I will

Ok, I looked at it from various angles, and did some heavy thinking about
it.

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.

Even if the lenght limit for sysfs entries (19 chars + NULL) is lifted in
2.6.26, the current proposal that would become stable in 2.6.25 is still
ugly, and not nearly close to the best we could do, IMHO.

The only technical reason I can see for the "devicename" part of the LED
name is to avoid clashes (or as a placeholder when you have no function).
However, it is the least important information for any sort of generic LED
tool (which is the only reason to even bother with a LED naming standard to
begin with), so it certainly should not come first in the name.  And there
are other ways to avoid clashes that waste far less real state than the
device name.

Can't we have "function[:color].<number>" instead?   And allow for a choice
of "devicename" or simply "led" instead of "function" for leds with no
defined or implied function?

It places fields in order of importance (thus it is far more user-friendly),
it wastes less real state (typically just two chars) to avoid clashes, and
it also follows what we already have on other sysfs subsystems (except for
the :color part, and I agree with you that it is a desireable thing to have
in there).

The clash-avoiding ".%d" postfix would be taken care of by the class.  If
two devices are registered with a "battery:green" name, you'd end up with
"battery:green.0" and "battery:green.1".  If just one device tries to
register "battery:yellow", you'd get "battery:yellow.0".

Later (for 2.6.26) I'd also suggest adding the color notion to the *class*
itself, including the notion of "undefined" color.  The class would take
care to add the ":color" part of the node name (when it is not "undefined")
and *also* export the color as an attribute. I can write this patch too, if
you want.

Would you take patches to implement the "function[:color].<ordinal>" naming
scheme, and try to merge them into 2.6.25?  Avoiding a bad ABI becoming
stable *is* an acceptable reason for a late merge.

-- 
  "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-17  3:59 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           ` Henrique de Moraes Holschuh [this message]
2008-03-17  9:51             ` LED naming standard for LED class Richard Purdie
2008-03-18  3:35               ` Henrique de Moraes Holschuh
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=20080317033458.GA20486@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).