Re: [lm-sensors] [PATCHv4 1/1] Hwmon: Add core/pkg Threshold

[Guenter Roeck <guenter.roeck@ericsson.com>]

On Sun, Sep 18, 2011 at 09:30:22AM -0400, Jean Delvare wrote:
> Hi Guenter,
> 
> On Sat, 17 Sep 2011 09:31:38 -0700, Guenter Roeck wrote:
> > The lm90 driver with its LM90_HAVE_BROKEN_ALERT flag has the same problem.
> > Sure, one can simply disable alerts forever after the first alert is triggered,
> > as the driver does right now, but that is really just as helpful as having
> > no alerts at all.
> 
> This isn't what the lm90 driver is doing. Look at the end of
> lm90_update_device(), alarms are re-enabled if needed. I agree that it
> isn't bullet proof, as it only works if user-space is reading at least
> one value repeatedly, but it's way better than what you described.
> 
Ah, I missed that. Not much better, though. It means that applications
would have to start polling after the first alarm is seen on a device,
and keep doing so until the last alarm is gone.

> > My current solution is to revert to in-kernel polling while alarms are active.
> > This way I can re-enable alerts after the alarms are no longer active,
> > and the additional overhead is quite low since the polling thread only runs
> > while there are active alarms.
> > 
> > If we declare that applications can only depend on 0->1 transitions, I would
> > still need in-kernel polling to be able to re-enable alerts. As a result, we
> > would end up with double polling - by the kernel _and_ by the application.
> > That would really be undesirable.
> 
> I agree. I suggested user-space polling because I didn't know there was
> a need for in-kernel polling. If you think that this will be the case
> for most drivers, then I have no objection to specifying that drivers
> should notify both directions or neither, i.e. no user-space polling.
> 
Ok.

Thanks,
Guenter

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