[RFC PATCH 2.6.12-rc2-mm2 0/2] i2c: new sysfs class "hwmon"

Dmitry Torokhov dmitry.torokhov at gmail.com
Wed Apr 13 18:34:44 CEST 2005

Sorry for breaking the thread (I was not subscribed to this list)...
I think that just simply linking current i2c device attributes intoclass structure is not the best thing to do. Since userspace needs tobe changed anyway (to a certain extent) we should evaluate whether itwould be beneficial to change layout too.
I would like to see something like this:
sys/class/sensors---fan---0---(min,in,div)                  |     |                  |     --1---(min,in,div)                  |                  |-temp---0---(type,min,max,hyst…)                  |      |                  |      --1---(type,min,max,hyst..)                  |                  --curr----0---(min,max,in)
This of course depends on Greg adding support for nested classes tothe driver code (how is it going, Greg?). Alternatively we couldflatten a tree a bit doingfan%d, temp%d...
We would have: sensors_register_fan, sensors_register_temp,sensors_register_curr, sensors_register_generic...
struct sensor_fan_dev {	char name[MAX_SENSOR_NAME]	int min, div;	struct class_device class_dev;
	int (*read)(struct sensor_temp_dev *);	int  (*start)(struct sensor_temp_dev *, int speed)};
struct sensor_temp_dev {	char name[MAX_SENSOR_NAME]	int type, min, max, hyst;	struct class_device class_dev;
	int (*read)(struct sensor_temp_dev *);};
This way every sensor input is registered as an independent classdevice, all their attributes are kept together, names are muchsimplier and there are less chances of clashes and I believe they areeasier to maintain. Other subsystems should also be able to add to thehierarchy without knowing anything about i2c internals.
What do you think?
-- Dmitry

More information about the lm-sensors mailing list