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

[Arjen de Korte]

> It would. But it may not be the only device matching. There may be two
> devices that match the same regular expression. In fact, one extreme
> case of this is where the user didn't specify any regular expression
> at all (perhaps she had only one UPS at the time). She might add a
> second UPS for testing purposes. If the first one gets disconnected
> due to wire congestion or whatever, NUT should try to reconnect to the
> same device that just got disconnected, if possible. This was the
> purpose of the exact_matcher.
>
> On the other hand, if our user plugs in UPS2, then accidentally
> unplugs UPS1, and then plugs UPS1 into a different USB port, I think
> the driver should still try to connect to UPS1, and not UPS2. This is
> why I don't think "bus" belongs in the exact_matcher. It was intended
> to match a device, not a location.

Agreed, the "Bus" is now #ifdef'ed so that I can simulate adding a
different UPS'es which should (or should not) be matched depending on a
new variable "reconnectfail" that I intend to add (see below).

>> What I want to achieve here, is predictable behaviour. In 'exact' mode,
>> the driver would always reconnect to the device it connected to on
>> startup, while in 'regex' mode it would behave as if you would restart
>> the whole driver.
> Yes, but reconnection is not a user-initiated event. With some
> devices, it happens once every half-hour. So behaving exactly as if
> the whole driver was restarted was perhaps not the most desirable
> behavior.

Agreed. We should have something in between too.

> But I agree that it is a murky issue. Perhaps we should go back to
> behavior (1) as the only alternative on reconnect (and behavior (2) on
> a first connection of course).

I think there is no question that the default behaviour should be the same
as it has always been. Which means that the driver reconnects through the
exact->regex->subdriver matchers and if this doesn't work, doesn't
fallback to any other method, but instead will retry.

> Even in this case, I would *still* use MODE_OPEN, because even the
> exact matcher is not 100% sure to open the exact same device. Many
> vendors don't include a serial number, for example.

If two UPS'es are attached that can't be distinguished from one another by
neither the 'exact' matcher nor the 'regex' matcher, the behaviour will be
unpredictable from the start. What should we do if *both* loose their
connection, because the hub they are connected to was replugged?

>> The problem with the 'regex' matcher we have now, is that it may also
>> require the subdriver to change, so behaviour (2) and (3) are not
>> possible yet. Currently, usbhid-ups only checks this on startup. So you
>> may be able to open a new device through the 'regex' matcher, only to
>> find out that when you try to read anthing from the device, you have the
>> wrong hid2nut tables, because we never tried to see if we still use the
>> same subdriver. Bummer.

Forget about the above, this has been solved in the mean time by doing
this in the callback function, after parsing the report descriptor. There
is no more reason why we couldn't allow a totally different device to
match. It definitly should *not* be the default behaviour though. :-)

> That is true. Perhaps we should stick to behavior (1) for this
> reason. At least the exact_matcher will guarantee that it's the same
> vendorid/productid.

I propose to add a new option to "ups.conf" that would tell how we should
deal with reconnects:

reconnect = [ retry, reload, restart ]

[retry]
Match the device with the 'exact->regex->subdriver' matchers as we do now
(should be the default). All variables will be read again from the UPS, to
make sure we have fresh data.

[reload]
Match the device through the 'regex->subdriver' matcher and after reading
the report descriptor and vendor specific formatting applied, run the
'exact' matcher. If this matches, refresh all variables / commands from
the UPS. The difference with the retry mechanism is that the subdriver
specific formatting is applied *before* creating/using the 'exact'
matcher, which might be useful for devices that don't report the serial
number in the usb_device structure or where we want to include other
parameters from the HID tree in the matching mechanism. If this creates a
unique device identification, there is no reason to assume this is a
different device.

[restart]
Same as reload, but don't run the 'exact' matcher after reading the report
descriptor. Since this may mean we're connecting to a completely different
device we brutally DELCMD/DELINFO everything we have and act as restarting
the driver (including creating a new 'exact' matcher). Not for the faint
of heart.

In most cases, I think either 'retry' or 'reload' should be fine. The
'restart' mode is only needed in case you really have no clue what you're
connecting to and just hope for the best that this is the UPS that is
powering your all important application. ;-)

Best regards, Arjen