Hi! > > >+ perhaps it would not need explicit maintainer, just assign names > > > carefully > > > > We also need to decide on clear convention about units. Are they in > > the output and/or filename? Filename is best, I think, since it's > > impossible to miss and works nicely for input attributes too. > > Actually, this whole thing could probably just go under the 'hwmon' > interface, as it already handles other hardware monitoring events. I > don't see how a battery would be any different, do you? Heh... yes, hwmon already has voltage, current, and more importantly, a maintainer. I'd still prefer batteries to go into /sys/class/battery/... they are really different from lm78-style voltage sensor and I'd not expect battery applet to understand all the fields "normal" hwmon exports. But conventions developed by hwmon group look sane and usable. Actually I do not see "hwmon infrastructure" to exist. Every driver just uses sysfs directly. I'm not sure that the best option -- "input-like" infrastructure can make drivers even shorter -- but perhaps just directly using sysfs is best for simple task like a battery? Jean, any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
