[lm-sensors] issue with clearing alarms

[khali@linux-fr.org (Jean Delvare)]

Hi Jim,

> Looking again, I see a point of confusion at least, and a possible problem.
> It may be one of interpretation, but is worth checking, and possibly 
> documenting.
> 
> The *not-yet-read* property pertains to the scan done by update_device(),
> since thats what reads all sensors the driver supports.
> But its easy to misconstrue not-yet-read as a property on the individual 
> alarms.
> 
> More importantly, any single read of any property will clear unrelated 
> alarms.

You are 100% correct. Things are as you describe, by driver design.

> So, with the usual caveats (Ive done something wrong, immature code, etc)
> I see a few possibilities:
> 
> 1 - Document the fact - tell users not to do that.
>     this isnt unreasonable, and far simpler..

The user can't do anything. The ones we need to tell are the
application authors. The end user looks at the temperatures in his nice
GUI, and doesn't decide what is read and when. At best he/she can
select the global refresh rate, and that's about it.

> 2 - sensors-deamon locks the directory to preclude loss of alarms (is 
> this possible ? bad idea ?)

Which daemon?

> 3 - dunno

4 - don't care:

What's the point in spending efforts to make sure that the application
will see the one-time alarm, while you have absolutely no way to know
if the user will see it? Unless the application keeps the alarm on
until the user clicks to confirm that he/she did see the alarm... This
doesn't sound very friendly.

All GUIs I know of do not present the alarm data at all, by the way.
Could be because libsensors doesn't make their access very friendly at
the moment... But it could also be because end users don't care - they
can simply compare the measurement to the limits, or even judge the
measurement by themselves. The alarm bits are redundant.

Furthermore, I don't expect any application to actually do selective
reads. I expect them to read all the values at once, and our drivers
will work just fine in that case. Do you know of any exiting
application that does otherwise?

In the real world, one-time alarms don't matter. I don't get why chip
designers almost all did implement alarms that way. Their main use
right now is for us to write and debug drivers.

So, as much as I agree that there is a flaw in our design, I'd say
fixing it isn't worth the effort.

-- 
Jean Delvare