LED devices

[Richard Purdie]

On Wed, 2007-05-30 at 16:34 +0100, Richard Hughes wrote:
> I've talked with other kernel guys here at red hat and they don't think
> putting properties in the handle is a good idea.
> 
> I've cc'd Kay, Greg KH and a few other developers for comments.
> 
> To summarize, the LED device class creates a device with a ":" delimited
> handle, where properties that are not going to changed get included in
> the handle name for userspace to parse with sscanf. For
> example, /sys/class/leds/thinklight:blue:keyboard_backlight/brightness
> 
> I think this breaks the one-value-per sysfs file rule and sure makes it
> more difficult to extract information in HAL. The backlight class should
> have an attribute "color" and "function" so new properties can be added
> (or ones that make no sense removed) without breaking API, but the
> maintainer doesn't like that idea.

I will put my side (as the above maintainer) across. When deciding on
the naming for the LEDs in /sys/class/leds/ we had several choices.
Taking my handheld as an example, some choices were:

/sys/class/leds/led0/
/sys/class/leds/led1/

/sys/class/leds/spitz0/
/sys/class/leds/spitz1/

/sys/class/leds/spitz:amber/
/sys/class/leds/spitz:green/

The first contains no useful information, the second one is only
fractionally better, the third is actually quite useful. Faced with the
third name, a person can actually point to the right LED on the device.

As far as the class is concerned, LED colour is a static property (it
could handle multi coloured through multiple LED devices).

The LEDs class therefore said it would have a naming policy for the LEDs
consisting of "name:colour" and this was documented in
Documentation/leds-class.txt.

Yes, we could easily add a colour attribute to the class but since the
information is already available in a machine readable place, why waste
the memory for the directory entries and code to access them?

The point of the class interface is to define a standardised way of
accessing a type of hardware. The LED class has a well defined (and even
documented) interface.

If reading names from a string causes HAL problems, its not really
living up to its name...

There have  been discussions about a function attribute and to me,
that's still a part of the LED name as it identifies the specific LED,
particularly when a device has LEDs with the same colour. For my example
that would become:

/sys/class/leds/spitz:amber:charging/
/sys/class/leds/spitz:green:hdd-activity/

The documentation does state "The naming scheme above leaves scope for
further attributes should they be needed" clearly implying its delimited
by the ':' character so anyone doing sscanf("%s:%s",...) didn't read the
documentation.

No decision about including the function attribute has yet been made
although it appears to make sense and is compatible with the defined
'API' aka class interface.

Regards,

Richard