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

[Peter Selinger]

Arjen de Korte wrote:
> 
> 
> >> 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. 

Of course it is. What I meant is: who cares about predictability if
your driver segfaults? That seems to me to be a more serious issue.
Predictable behavior is desirable, but this burden can be put on the
user (use the -x bus option if you must have such a setup). Avoiding
drivers and devices to crash is not only desirable, but an essential
requirement. So MODE_REOPEN does something that is potentially
unsafe, by not re-reading and re-parsing the report descriptor.

There is one solution that would be safe and still would not require
reallocation of memory. One would have to change the behavior of
MODE_REOPEN so that it re-reads the report descriptor, and compares it
to the previously stored report descriptor. If they are the same, then
the report descriptor does not need to be re-parsed. If they are
different, then the device should not match. 

In other words, if the exact matching mechanism were extended to
include the full report descriptor (or a checksum thereof), then not
re-parsing it would be safe. 

However, reading the report descriptor requires opening the device,
and so this should be done in the second tier of matching (i.e., only
if the vendorid/productid and other such info has already been matched). 

-- Peter

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