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
