[Nut-upsdev] [nut-commits] svn commit r1041 - in trunk: .
Peter Selinger
selinger at mathstat.dal.ca
Sat Aug 11 10:02:28 UTC 2007
Arjen de Korte wrote:
>
>
> >> - If the UPS sends reports on the interrupt pipeline, we consider that
> >> enough proof that it is still there. At the same time, we assume that it
> >> keeps us informed of *all* important status changes, so that doing a
> >> HU_WALKMODE_QUICK_UPDATE is redundant then.
> > This latter assumption is probably not valid in all cases. For
> > example, since the interrupt value of
> > UPS.PowerSummary.BelowRemainingCapacityLimit was broken on Belkin, we
> > decided to go with UPS.BELKINStatus.BELKINBatteryStatus instead, which
> > is a variable that is *not* sent on the interrupt pipeline.
> >
> > In general, not every UPS that uses the interrupt pipeline can be
> > trusted to send all important values on it.
>
> I was already afraid of that, so I decided to explicitly mention this in
> the ChangeLog. You have a good point here. But so far, the only subdriver
> that uses the HU_WALKMODE_QUICK_UPDATE (by setting HU_FLAG_QUICK_POLL on
> relevant elements) is mge-hid. So for all but that one, the behaviour
> remains the same. I know that at least my Evolution 650 is quite verbose
> on the interrupt pipeline when something important happens (it will push
> even more parameters than we sollicit from it with a
> HU_WALKMODE_QUICK_UPDATE), so apparently MGE uses it (though I have not
> checked other models of course).
>
> In order to make the HU_WALKMODE_QUICK_UPDATE more useful, we probably
> need to set HU_FLAG_QUICK_POLL on "usb.status" elements for more
> subdrivers. For instance, on the "ups.status" for
> UPS.BELKINStatus.BELKINPowerStatus and
> UPS.BELKINStatus.BELKINBatteryStatus in belkin-hid.c (all of them). I'm
> reluctant to do this, since I can't test if this increased polling of
> these items doens't break these subdrivers.
I'm not sure how it could break anything; doesn't it just mean the
corresponding variables get polled more frequently? I'd be happy to
test the change, which seems very sensible, on Belkin and APC.
-- Peter
More information about the Nut-upsdev
mailing list