[lm-sensors] Kernel-provided labels

[Jean Delvare]

Hi Hubert,

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:
http://www.lm-sensors.org/ticket/2375

-- 
Jean Delvare