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

[Arjen de Korte]

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

OK, well keep the chains as they are.

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

Yep, I broke that part of libusb_open. Will correct it. ;-)

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

You're probably right here. Since it doesn't require any additional I/O,
the impact is likely to be negliable.

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

That is already implemented, as far as I can see:

	regex_array[5] = getval("bus");

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

We could also create a function in the subdrivers, that would be appended
to the list of matchers, once we have found a subdriver. Subdrivers not
needing this would simply provide a stub that always matches. This would
allow subdrivers the freedom to look anywhere in the UPS for data to match
on.

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

Agreed.

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

Indeed.

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

I'm not too happy about silently connecting to a device we *know* is
different from the one we connected to on startup. So no, I don't think it
is a good idea to re-create a new reopen_matcher if we reconnected to a
device through MODE_OPEN.

I understand that there are devices that look different upon reconnecting
and that's why we should allow to fallback to MODE_OPEN to make sure we
can reconnect to those. But if we have the choice to connect to a device
that matches the initial reopen_matcher (the one we created at startup)
and the device that we were connected to last, the first should be more
favored.

I even think we should add a 'relaxed_reopen' flag (or something like
that) that would need to be set to allow fallback from MODE_REOPEN to
MODE_OPEN. I would rather see a warning about stale data, than the driver
connecting to some other device. Broken UPS'es should not be made the
norm, although we should try our best to workaround known problems.

Best regards, Arjen