[Nut-upsdev] [nut-commits] svn commit r1072 - in trunk: .

[Peter Selinger]

Arjen de Korte wrote:
> 
> > In any case, R/W values would have to be re-read, as the set of
> > variables might have changed on reconnect, if the device connected to
> > didn't happen to be the same one (i.e., if the exact-matcher fails and
> > we fall back to the inexact method)
> 
> Indeed. And even if it is indeed the same device, the data may have
> changed anyway, so I agree that on a reconnect we should at least re-read
> everything. Unfortunately, we have no way to kwow if on a reconnect we
> have an exact or regex match, so this needs to be worked on too. On an
> exact match, it is probably OK to keep the report descriptor (it's the
> same device), while for a regex match we need to parse it again, right?

I wouldn't bother making the distinction. Re-parsing the report
descriptor takes next to no effort at all.
 
> > I wasn't sure if it was possible to add or remove variables and
> > instant commands, after the driver was already running, or if this was
> > only possible during the initial init(). Does the driver/upsd protocol
> > allow for the dynamic creation and deletion of variables? If not, the
> > "inexact matching" fallback is a bit of a leap of faith.
> 
> We have DELINFO and DELCMD to do just that. You can use these through
> dstate_delinfo() and dstate_delcmd(). I'm just a little worried on the
> impact this may have on server and clients though. To make sure that we
> don't duplicate variables and we use the most favored HID path (the latter
> is the most difficult to guarantee), the safest solution is probably to
> blow away all variables and commands and run hid_ups_walk in
> HU_WALKMODE_INIT again if we have an 'inexact' match. Probably with the
> exception of "ups.status" (and "ups.alarm") so that we're not causing
> unneccessary events in clients that are attached.

Makes sense. 

-- Peter