[lm-sensors] Kernel-provided labels

[lm-sensors] Kernel-provided labels

[Jean Delvare]

Hi all,

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.

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?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Kernel-provided labels

[Hubert Kario]

On Tuesday 12 May 2009 22:55:08 you wrote:
> Hi all,
>
> 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

>
> 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?

-- 
Hubert Kario
QBS - Quality Business Software
ul. Ksawerów 30/85
02-656 Warszawa
POLAND
tel. +48 (22) 646-61-51, 646-74-24
fax +48 (22) 646-61-50


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [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

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors