Jean Delvare wrote: > On Wed, 25 Nov 2009 10:51:38 +0100, Clemens Ladisch wrote: > > temp1_input: -1000 > > temp1_max: 40000 > > temp1_relative: 0 > > Should the values be labeled as "1 °C below normal" and "40 °C above > > normal", and how should the application know that 0 is to be labeled > > "normal"? It might make more sense to display the temperature just as > > "41 °C below max", in which case the actual value of temp1_relative is > > not used at all. > > Except that there may be no temp1_max, just a temperature value > relative to the "normal" operating point of the CPU. In that case we > can't fallback to the max limit. > > Even your initial proposal doesn't work there yet: the hwmon interface > has no standard name for "normal operating temperature", so we can't put > that name in temp#_relative. [...] > If the base has a meaning (normal operating temperature, or critical > temperature, etc.) we have to let the user know somehow. I chose that example because "normal" does not exist; and it's a bad example because "normal" actually has a meaning. Better take the AMD CPUs: The base of all relative values is zero (by definition), _not_ 70000, and the meaning of that base is just "70 °C below the temperature at which the processor wants 100% cooling". This base value is meaningless for any monitoring purposes. If any point on the scale has a meaning, it should be reported with some temp#_whatever file. However, the base itself does not necessarily have any meaning. As long as we have some corresponding _max or _crit limit that can be used for comparisons, we do not need a base value. Only if there is no known predefined limit do we need a temp#_relative value. > Or maybe create a new label (temp#_relative_label or similar) but I'm > not sure how we would integrate this into libsensors and applications. > In particular I am worried about translation issues if we make the > drivers too verbose. All known CPUs with relative temperature scale also have known _max limits, and I don't think that a CPU with relative scale and both unknown _max and _crit will ever be designed. In other words, temp#_relative* is not needed at the moment. I think we should not try to define how the semantics of such an unknown scale can be described. > > > Additionally it wouldn't fit in libsensors as it exists today. > > > > Then the best bet would probably be an entry like temp#_unit, with > > 0 = absolute °C (default); 1 = relative °C or °K; other values > > "unknown". Even if some silly scale is introduced later, applications > > that read this entry then know that they must not display a unit like °C > > for unknown unit specifications. > > This could work, yes. Note that current drivers and libsensors don't > have/know about this file yet, and they generally use an absolute °C > scale. So the absence of temp#_unit file would be interpreted exactly > as if the file was there and contained value 0. > > (I'd rather name that file temp#_scale - but that's an implementation > detail.) Like this? --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -314,6 +314,19 @@ temp_reset_history Reset temp_lowest and temp_highest for all sensors WO +temp[1-*]_scale Temperature scale type. + Integer + RO + 0: millidegrees Celsius (default if no _scale entry) + 1: relative millidegrees Celsius; see below + 2: millivolts; see below + other values: unknown + When scale=1 (relative), the temperature value 0 does not + correspond to zero degrees Celsius but to some unknown + temperature. In this case, temperate values should not be + interpreted or displayed as absolute values and make sense + only when compared to other values of the same channel. + Some chips measure temperature using external thermistors and an ADC, and report the temperature measurement as a voltage. Converting this voltage back to a temperature (or the other way around for limits) requires Hmm, which drivers use millivolt temperatures? Best regards, Clemens _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
