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

[Arjen de Korte]

>> If two UPS'es are attached that can't be distinguished from one another
>> by neither the 'exact' matcher nor the 'regex' matcher, the behaviour
>> will be unpredictable from the start. What should we do if *both* loose
>> their connection, because the hub they are connected to was replugged?
> This is not a question of predictability, but of soundness (i.e., no
> segmentation faults). Two devices that cannot be distinguished by
> either the exact or regex matchers might still be very different
> devices. MODE_REOPEN does not re-read the report descriptor. If the
> driver later tries to set a variable, who knows where it might be
> written.

It *is* a question of predictability. Since NUT doesn't use (if this is
possible at all) port locking on the USB ports, if you need to monitor two
different UPS'es, they *must* be distinguishable through the regex
matcher. Otherwise both drivers would connect to the same UPS on startup
already, the first one that matches the regular expression. Try it out,
copy the entry you already have for your UPS, give it a new name and
restart the lot. You'll find that both driver instances will connect to
the same UPS without ever complaining. In other words, usbhid-ups doesn't
support multiple UPS'es if they can't be distinguished from one another.
So connecting two 'identical' UPS'es won't work as expected from the start
already and we're trying to fix a theoretical setup that won't work as
expected in the first place.

[...]

> The 'restart' mode has one additional use: if you have only one UPS,
> so you *know* it's the correct one; but for some reason it changes its
> serial number or product name on reconnection. There has been at least
> one report of a device that did this (it changed the strings to empty
> strings on reconnection, for no apparent reason).

In the mean time, I have removed the restart option. I think this
situation can be dealt with through the 'matching = delayed' option
though, provided the driver in question will use the report descriptor to
get to the values of manufacturer, model and serial number.

Best regards, Arjen