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

[Peter Selinger]

Arjen de Korte wrote:
> 
> > Note "regex_matcher", not "reopen_matcher", in the second call, and
> > also the changed MODE flag.
> 
> In order for this to work, we would need to split these into
> 
> 	reopen_matcher
> and
> 	regex_matcher->subdriver_matcher
> 
> So the linking between these in upsdrv_initups() should be removed.
> 
> > Then all the complicated stuff could be removed from libhid/libusb
> > (different non-zero return codes for matchers etc).
> 
> Makes a lot of sense.
> 
> > I am not sure the code in libusb_open() is correct anyway, as matching
> > a chain of matchers should mean matching *all* the matchers contained
> > therein, not just the first possible one. For example, after a positive
> > reopen_match, one should still check regex_match also.
> 
> The latter makes no sense to me. An exact match is a subset of (hopefully
> one) of the devices that match the regex matcher. If you already have an
> exact match, you therefor are guaranteed to have a match on the regex
> matcher, since that is how you got there in the first place through the
> initial call to HIDOpenDevice() with MODE_OPEN. The added regex match
> would effectively be a no-op then.

Well, almost. There is a theoretical possibility that a device, which
is not the same as the original device disconnected, matches all the
data in reopen_matcher, but doesn't match subdriver_matcher for some,
yet unimplemented, reason. 

The logic in libusb_open should be that a device has to match *all*
the matchers in a chain, because we need to chain the regex_matcher
and subdriver_matcher in this way.

By adding the reopen_matcher to the front, we are guaranteed to make
the check strictly more strict. I agree that this is currently
redundant w.r.t. regex_matcher, but there is virtually no cost to this
redundancy. 

Also, the idea was that eventually, other mechanisms could be added to
regex_matcher, for example, one could require the device to be on a
particular USB bus (roughtly, a particular physical port).  Or some
vendor-specific device might have a serial number that is stored not
in the usual place, but in some vendor-specific place. The
regex-matcher (but perhaps not in general the reopen_matcher) could be
extended to look for such information.

This info wouldn't necessarily go into reopen_matcher, so it would
still make sense to check both of them upon reopening. 

Logically, on reopen, a device should (1) match all the original
criteria, and (2) according to some measure, should be the same as the
disconnected device. I guess what I am trying to say is that it is
only a coincidence that (1) is a subset of (2). 

> 
> 

Also, there's another flaw in the reopening code, I think. If we try
and fail to reopen, and fall back into the "open any matching device",
then should we also create (or update) a new reopen_matcher? If there
is another disconnect at a later point, the question is: should we try
to reconnect to the original device, or to the one we most recently
connected to? I think most recent would make more sense, because all
the variables would not have to be re-parsed. 

-- Peter