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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
