Re: [RFC] [PATCH 1/2] introduce ALS sysfs class

[Jonathan Cameron <Jonathan.Cameron@gmail.com>]

Pavel Machek wrote:
> On Tue 2009-09-22 13:42:23, Jonathan Cameron wrote:
>   
>> Zhang Rui wrote:
>>     
>>> Hi, Jonathan,
>>>
>>> this is the refresh ALS sysfs class driver.
>>> I just introduced one sysfs attribute "illuminance", because
>>> I didn't catch the exact meaning of the others like "???infrared".
>>> So it would be great if you can generate an incremental patch
>>> to introduce the other optional attributes needed, and update
>>> the documentation as well. :)
>>>       
>> Will do, though may just leave it out of first pass of drivers
>> (as it may be controversial and it would be nice to get something
>> in place before the arguments begin!)
>>
>> All looks nice and clean. The only real question is whether
>> we want to standardize naming of devices under sysfs (like hwmon does)
>> or allow the individual drivers to do the naming?
>>     
>
> Allow the drivers to do the naming. Having useless name like "als0",
> with als0/name telling me what the driver is is bad.
>   
This topic came up again in the discussion of the tsl2550 driver port.

Jean Delvare raised a point that I'm inclined to agree with (with several
more ports from elsewhere in the kernel underway).

.... (quoted from [PATCH] ALS: TSL2550 driver move from i2c/chips)

> I'd imaging that als-class devices are simply named als%u. Just like
> > > hwmon devices are named hwmon%u, input devices are names input%u and
> > > event%u, etc. I don't know of any class pushing the naming down to its
> > > drivers, do you? The only example I can remember are i2c drivers back
> > > in year 1999, when they were part of lm-sensors.I have personally put
> > > an end to this years ago.
> >
> > This debate started in the als thread. Personally I couldn't care less
> > either way but it does need to be put to bed before that subsystem merges.
> > To my mind either approach is trivially handled in a userspace library
> > so it doesn't matter.  I don't suppose you can remember what the original
> > reasons for squashing this naming approach were?
>
> Code duplication. Having the same unique-id handling code repeated in
> 50 drivers was no fun, as it did not add any value compared to a
> central handling.
>

So does anyone have a strong objection to moving over the more conventional
als0/ naming and move the id handling into the als core?

Note that unless there is a clear reason for doing it any other way it will
probably meet resistance beyond Jean and myself.

Jonathan