Subject changed to reflect change in topic, and to call attention to others who might be interested. On Wed, Mar 26, 2003 at 05:26:54PM -0500, Mark Studebaker wrote: > If you rename the files and/or split multivalue files into separate > single value files, or change the format of the contents, > and continue these changes across the 30 or so "chip" drivers of ours, > you will completely blow up our libsensors library, and userspace programs. Well ideally libsensors can change and then userspace programs will never know the difference :) I need to start digging into the libsensors code to be able to back this up, but at first glance I think it's feasible. > If all the patches do is move all the files unchanged from > /proc/sys/dev/sensors/... to /sysfs/... then that change is much much easier > to incorporate in our programs. True, but multi-valued files are not allowed in sysfs. It's especially obnoxious that you have 3 value files when you read them, but only expect 2 values for writing. The way I split up the values in the lm75.c driver shows a user exactly which values are writable, and enforces this on the file system level. I don't want to detract from all of the work you, and the lm_sensors group has done in the past, it's quite nice. I'm just trying to fit the drivers into current kernel policies in the best way possible. Remember, I want this to work, and for everyone to come to an understanding. > lm_sensors /proc naming standars for sensors chip drivers: > > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/developers/proc Thanks for the link. I don't really think this is a problem. As an example, the temp files, which are currently defined as a proc file with this description: Entry Values Function ----- ------ -------- temp, temp[1-3] 3 Temperature max, min or hysteresis, and input value. Floating point values XXX.X or XXX.XX in degrees Celcius. 'temp' is used if there is only one temperature sensor on the chip; for multiple temps. start with 'temp1'. Temp1 is generally the sensor inside the chip itself, generally reported as "motherboard temperature". Temp2 and temp3 are generally sensors external to the chip itself, for example the thermal diode inside the CPU or a termistor nearby. The second value is preferably a hysteresis value, reported as a absolute temperature, NOT a delta from the max value. First two values are read/write and third is read only. Could be rewritten to say: Entry Function ----- -------- temp_max[1-3] Temperature max value. Fixed point value in form XXXXX and should be divided by 100 to get degrees Celsius. Read/Write value. temp_min[1-3] Temperature min or hysteresis value. Fixed point value in form XXXXX and should be divided by 100 to get degrees Celsius. This is preferably a hysteresis value, reported as a absolute temperature, NOT a delta from the max value. Read/Write value. temp_input[1-3] Temperature input value. Read only value. If there are multiple temperature sensors, temp_*1 is generally the sensor inside the chip itself, generally reported as "motherboard temperature". temp_*2 and temp_*3 are generally sensors external to the chip itself, for example the thermal diode inside the CPU or a thermistor nearby. That would give us one value per file, use no floating point in the kernel (fake or not) and generally make things a whole lot more orderly. Also, if a sensor does not have a max value (for example, I don't really know if this is true), instead of having to fake a value, it can just not create the file. Then userspace can easily detect this is not supported, and is not a placeholder value. Does that sound reasonable? thanks, greg k-h
