LED devices

[Richard Hughes]

On Fri, 2007-06-01 at 13:59 +0100, Richard Purdie wrote:
> On Fri, 2007-06-01 at 13:36 +0100, Richard Hughes wrote:
> > On Fri, 2007-06-01 at 13:18 +0100, Richard Purdie wrote:
> > > On Fri, 2007-06-01 at 13:04 +0100, Richard Hughes wrote:
> > > Several reasons:
> > > 
> > > * I want to keep the names descriptive (which is allowed afaict)
> > 
> > Then we can use apple_power_on, thinkpad_charging, logitech_low_power.
> > The colour of the led is not always the best descriptor.
> 
> Agreed, which is why I've said I'll accept some optional notion of
> function in the name by extending the API as discussed previously.

You are _changing_ the API. This is something you would not have to do
if you just used standard sysfs attributes.

> Of course by your own argument we'll have to provide a property
> attribute for that too since conveying that information in the name only
> isn't allowed.

Sure, an optional attribute called "description" would also be good.

> > > * If we remove colour from the names we break the existing API as
> > > documented.
> > 
> Look harder, there are at least the following users using that naming
> scheme just in drivers/leds:
> 
> leds-corgi
> leds-tosa
> leds-spitz
> leds-h1940
> leds-locomo
> leds-gpio
> leds-ixp4xx-gpio

Yes, most added by you or John, I'm looking at the common case.

> > > * Drivers should only specify the colour in one place.
> > 
> > Yup. Agree, which to me suggests that a descriptor to the led
> > "discharging" is better than "amber", and then if the led colour ever
> > changes from model to model (like the thinklight) then we only have to
> > change one property and not the device name.
> 
> The LED function changes model to model too. The spitz driver works on
> two models, one where the green LED is marked as mail, the other where
> it is marked as HDD activity. So no, that argument doesn't stand up.

How does this help userspace? Two devices where the led is the same
device name with two completely different purposes.

The sysfs classes are _not_ just a convenient way for you to talk to
LEDs using a specific bit of software, they are meant to be general
purpose abstractions to be used by userspace interacting with hardware. 

You've not explained any good reasons for not doing the same as 99% of
the other sysfs class abstractions, i.e. using attributes (that are
supported using libsysfs), and I am beginning to loose patience with
this discussion.

The sysfs maintainer has asked you not to use ":" in the device name to
separate properties and I haven't found one person who thinks this is a
good idea.

Richard.