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

[Arjen de Korte]

>> > 2) we never re-read the report descriptor, and therefore never
>> >    compared that it was identical to the previous one,
>>
>> I agree. Theoretically, someone could have connected the UPS to a
>> different system in the mean time, have changed some R/W values and we
>> would never notice those changes.
>
> No, changeable R/W values are not part of the report descriptor.

I was referring to the NUT variables that have the HU_FLAG_STATIC or
HU_FLAG_SEMI_STATIC here. We only read these on startup and when running
instcmd/setvar respectively. Apologies for the confusion.

> The report descriptor defines the usage tree and is usually static.

I knew that.

[...]

> 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 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.

>> > If people have more than one UPS, and they care which is which,
>> > they anyway have to specify the vendorid or productid or whatever, to
>> > make it unique.
>>
>> This is already the behaviour now. The first time you start a driver, it
>> will connect to the first device that matches. If you start it again
>> with
>> the same parameters, it will fail, even if another device is free that
>> would match.
>
> I didn't follow that. If you have two devices, and you start two
> driver instances with the same parameters, the first driver will
> connect to the first device found, and the second to the second, I
> thought?

If memory serves, we've had some questions about situations like this a
while back, where people complained that if they fired up two drivers,
they would both connect to the *same* UPS (unlike what I stated above). I
don't know if this still happens though, this may be outdated and I can't
test this. Maybe Arnaud can check this out, by connecting two identical
units to the same server and see if this works?

Best regards, Arjen