[lm-sensors] Kernel-provided labels
khali at linux-fr.org
Wed Jul 22 14:20:09 CEST 2009
On Tue, 12 May 2009 23:19:52 +0200, Hubert Kario wrote:
> On Tuesday 12 May 2009 22:55:08 you wrote:
> > Kernel-provided sensor labels can be problematic when the user tries to
> > apply a compute or ignore statement. In general, one can comment out
> > all label statements in the configuration file or run "sensors
> > -c /dev/null" to see the symbolic names of all inputs (in0, temp1
> > etc...) However, in the case where kernel-provided labels are
> > available, libsensors will process them nevertheless, so the user has
> > no way to see the symbolic name for the input.
> > I can think of different approaches to solve this issue. I wonder which
> > one other developers and users think should be implemented.
> > 1* A new command line parameter to disable the processing of
> > kernel-provided labels (say: --no-kernel-labels.)
> > 2* A new command line parameter to disable the processing of
> > kernel-provided labels and configuration files (say: --raw.)
> > This is a shorter alternative to "sensors -c /dev/null
> > --no-kernel-label".
> > 3* A new sensors output format which would display all available
> > symbolic names of a device, possibly with kernel-provided and
> > user-provided labels in a table.
> I'm voting or this one
> this could be a "verbose" output. IMO as the complexity of lm-sensors
> increases the need for such output mode will only rise
> also it could be used to insert detailed descriptions of specific sensors, so,
> for example, the user could get info that the "CPU temp" is, in fact the
> "Tcase CPU temp" ─ a heat spreader temperature ;)
> this would increase user friendliness greatly
Honestly I don't quite see the relation between my initial point and
your own proposal. I am also skeptical that there's anything that needs
to be done: if you want "Tcase CPU temp" as the label, just set the
label to this in /etc/sensors3.conf and be done with it? Attaching a
short description (label) _and_ a long description to each sensor seems
overkill to me.
> > 4* Allow kernel-provided labels to be used in compute statements
> > instead of symbolic names.
> > 5* Something else, speak up :)
> > Option 4 seems technically complex to me, and error-prone
> > (kernel-provided labels are not guaranteed to be unique.) Option 1 is
> > very specific, I tend to prefer option 2 which is more generic and can
> > evolve over time. Option 3 may be interesting for other reasons,
> > including debugging and a valuable alternative to walking the sysfs
> > tree.
> > As far as I can see, options 1, 2 and 3 all require that we extend the
> > libsensors API.
> > Opinion anyone?
I have created a ticket to track this issue:
More information about the lm-sensors