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

[Arjen de Korte]

>> It's true that reading nonexistent data might not cause a segfault.
>> However, reading data and misinterpreting it (because it happens to be
>> in a numbered report which exists in both the current device and the
>> previous one, but whose contents might be something totally different)
>> can lead to a system shutdown in the worst case. Similarly, writing
>> variables whose interpretation is unknown can mess up the UPS state.
> I'm sorry, but this is only a theoretical problem. As I stated many times
> before, the usbhid-ups driver won't support multiple UPS'es that can't be
> distinguished through the regular expression matching. It never has and it
> never will. As a result, I don't think it is too much to ask from people
> that they need to restart the driver (manually) if they replace their UPS
> by a different unit. So we can assume that when we have a match on the
> exact matcher, this will be the same device as before. We should make it
> much clearer in the documentation that if you want to monitor multiple
> UPS'es, the regular expression matching is *not* optional, but mandatory
> instead.

In addition to this, in order to make this situation occur in the real world

1) both must have the same VendorID:ProductID, Product- and Modelnames and
Serialnumber (ie, they can't be distinguished through a regular expression
matcher)
2) the numeric HIDPaths must not only lead to different, but also
conflicting values in the UPS

While I agree that the first is quite possible (we've seen examples for
Tripplite for instance), I doubt the second will be. It would mean that
the vendor would need two separate USB versions for their bundled Windows
software also (after all, these devices can't be distinguished from one
another by 1). While theoretically that may be possible, it would lead to
serious problems when people upgrade from one type of UPS to another from
the same vendor. It would be insane to do that, so when at least the
VendorID:ProductID matches, you shouldn't have to expect conflicting
HIDPaths and reading the report descriptor again for that reason only is
not needed.

Best regards, Arjen