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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:26 EST