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

[Peter Selinger]

Arjen de Korte wrote:
> 
> > 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");

Good point. So the reopen_matcher does, in fact, not subsume the
regex_matcher completely, because "bus" is not checked by the
reopen_matcher. The idea is to try to reconnect to the same device,
even if it's on a different bus, *unless* the user specified a 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.

Yes. This can wait until it's actually needed though. 
 
> > 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.

Fair enough. But I think there might still be a problem in the current
code, where I am not sure if the HID tables will be reloaded if we
connect first to device A, then to device B, and then reconnect to
device A again later. At the last connection to device A, "reopen" was
successful, and if we're not careful, device A might be running with
B's HID-tables. I haven't checked the code to see if that's what's
currently happening.

-- Peter