LED devices

[Richard Purdie]

On Wed, 2007-05-30 at 14:16 +0100, Richard Hughes wrote:
> On Wed, 2007-05-30 at 13:55 +0100, Richard Purdie wrote:
> > 
> > > What's the big problem having names such as "thinklight" and then
> > > another attribute of "color"?
> > 
> > Each attribute uses memory for the sysfs entry and code for the access
> > functions. The value will never change. Exporting the information as
> > part of the device name seemed like a neat solution.
> 
> NO! This is not what sysfs was designed for. In that logic:
> 
> /sys/battery/batt1:lion:rechargeable:sanyo:14400
> /sys/battery/batt1::rechargeable::11000
> 
> Would be a valid devices. This means _nothing_ to userspace.

It depends whether the device names have a defined meaning or not. The
LED device names were defined in a particular way such that the colour
was extractable. Certainly you could never do this with device
parameters that could change (and for the LED class, colour is defined
to be fixed, there are comments on bi/tri/multi coloured LEDs in the
docs).

To be honest, the LED device names are a lot more meaningful than
"batt1", "batt2" and "batt3" which really do tell you absolutely
nothing.

> If we have to parse the values in sysfs device names then we might as
> well go back to the horrors that are /proc. This is bad. One value per
> file, simple as that.

This doesn't break that rule. We just encode some information into the
device name. You don't need that information to control the LED and it
is machine extractable.

The whole idea behind /sys/class/ is you define a standard interface
which is exactly what the LED class does.

>  I'm surprised this hasn't been ripped to pieces on LKML already.

It was discussed, no objections were raised.

Regards,

Richard