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

[Peter Selinger]

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

Your doubts are probably warranted; however, I have seen several
devices with small bugs in their report descriptor; it's quite
conceivable that they would fix them without updating the version
number. Also, I don't like to rely on assumptions about the sanity of
vendors; they are often misplaced (e.g. Belkin does not even comply
with parts of the USB specification). 

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

Not if the Windows software actually parses the HID tree. It is the
usage paths (such as UPS.Flow.ConfigFrequency) that are fixed in the
bundled driver, not their mapping to physical report numbers. The
latter are probably generated by the firmware compiler and could
easily change without notice. 

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

The report descriptor is a mapping from HIDPaths to physical report
locations.  Your argument proves that HIDPaths should not change when
people upgrade; however, without re-reading the report descriptor,
this does not imply that the physical report locations don't change. 

-- Peter