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

[Arjen de Korte]

>> * drivers/libhid.c:
>> - The 'exact' matcher now also matches the Bus too (this won't
>> change as long as the USB plug is not removed). If you don't like
>> this, use the 'regex' matcher instead.
> Ooh, I don't like this last one at all. One of the main reasons a
> device might get disconnected is that the user physically unplugs it
> while it is in operation, and then plugs it back in. Unlikely in a
> server configuration, but not so unlikely for desktops.

I think you missed the following message, which explains why I think this
is a good idea after all:

http://lists.alioth.debian.org/pipermail/nut-upsdev/2007-August/002471.html

> Perhaps they
> had to physically move the machine, or just untangle some cables. The
> user may or may not manage to hit the same physical plug, or even to
> remember which one it was. It was a useful feature of NUT that it
> handled such events transparently.
>
> I suggest reversing this change.

Please comment to the aforementioned message instead.

>> * drivers/usbhid-ups.c:
>> - The behaviour of reconnect is now depending on the 'reloadmatcher'
>> variable. By default, it uses 'exact' matches, but this can be
>> changed to 'regex', which me ans that it will use MODE_OPEN instead
>> of MODE_REOPEN. Essentially, it will beha ve exactly like starting
>> again.
>
> Shouldn't the default be to use exact matching whenever possible, and
> fall back to MODE_OPEN matching on failure (i.e., the currently
> intended behavior)?

No. In some applications where you are certain that nobody touched the
hardware (datacenter, remote configurations) you'd rather get an error,
than that the driver is silently 'correcting' the situation, which may
yield the correct result, but also might start monitoring a different UPS
that happens to be plugged in the USB port, but is not being monitored
yet, nor is providing power for your server.

> The other choice, which a user might request, is
> strict matching, i.e., to enforce exact matching all the time. I am
> not sure why anyone would request exact matching to be specifically
> turned off. Do I interpret the above log message correctly that the
> user now only has a choice between always-lax and always-strict
> matching?

Yes. What is open to discussion, is what the default should be. I also
pointed that out.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57