Error messages on ignored values

Jean Delvare khali at
Fri Feb 4 20:09:43 CET 2005

Hi Michael,

> > The approach you propose is slightly different, since the user would
> > have to put "ignore" lines in his/her configuration file in order to
> > dismiss the error message. So, while it looks cleaner, I am not sure
> > it is the way to go. If we do what you propose, we are likely to get
> > many reports about the errors, which aren't really errors.
> But there may be an error. What I don't like about just dropping the
> error is that we don't know if the file doesn't exist because that
> sensor doesn't exist, or there is another error because of a larger
> problem brewing.

Agreed, this is really only a quick hack, and not a nice one. We might
hide errors. However, it is believed that if one possibly-missing value
would actually raise an error, the other values would return similar
errors, so it is unlikely that actual errors would go unnoticed. It's
not like we would hide all errors; typically we only ignore a few ones.

> I've attached a patch that does the above. After writing it, I'm
> thinking there may be a better way to do this. The patch now checks
> for SENSORS_ERR_PROC, which is a pretty generic error returned from
> the library.

True, I don't think there is much chance that you get a different error
at this point, so it probably doesn't make any difference with just
ignoring the error. But that's stil nice.

> I think a better way to do this is to keep the changes to
> print_vt1211 that skip the print if the channel is ignored, but
> instead of checking sensors_get_feature for a specific error code, a
> function is added to the library to determine if a channel exists, and
> factor the result of that call into sensors_get_label_and_valid, so
> that valid would be false that channel is ignore, or if the file for
> that channel doesn't exist.
> If you think this is a good idea, let me know, and I'll take a stab at
> it.

I don't think it's worth the effort. Face it, libsensors is totally
procfs-centric, and won't ever properly deal with the new sysfs
interface. It needs to know everything about each chip to display
convenient results. With the new standardized sysfs interface it should
be possible to design a new library which doesn't need any knowledge
about the chips themselves, but would discover everything it needs from
the sysfs interface. If we are going to spend energy on making things
better for 2.6 kernels, we'd better start working on this library than
waste time on the old one, IMHO.

I'll apply your patch, thanks.

Jean Delvare

More information about the lm-sensors mailing list