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

[Arjen de Korte]

>> Yes. What is open to discussion, is what the default should be. I also
>> pointed that out.
>
> Okay, perhaps I am misunderstanding. There are three possible
> behaviors on reconnection:
>
> (1) *always* match strictly the same device, and give an error otherwise,
> (2) *always* match laxly; do not even attempt strict matching, even if
>     it would succeed.
> (3) try strict matching first, and use lax matching as a fallback.
>
> Option (3) used to be the default, and in fact it used to be the only
> possible behavior.

No, we never had that, until I started messing with this code a few days
ago. We would always use 'regex' matching on the first connect and
'strict' matching on reconnects.

> If I understand your log message correctly, you have now eliminated
> option (3) altogether, giving the user a choice only between (1) and (2).

It never existed, although by adding the 'Bus' to the exact matcher, I
made the exact matcher a little more strict.

> This would be a very bad idea in my opinion. I cannot think of any
> situation where behavior (2) would be preferable to behavior (3).

You suggested it yourself, a couple of days ago, when you said that we
should probably always reconnect in MODE_OPEN, while I bargained to keep
the MODE_REOPEN in. Effectively, that is the same as option 2 if you don't
change the reopen matcher (which we didn't discuss at that time however).

> Clearly, if the exact matching device is available, we should try to
> connect to it. The question should only be what to do if the exact
> matching device is not available. Therefore, the user should be given
> a choice between (1) and (3), and not between (1) and (2).

I really don't see a point here. The device has matched on the first
attempt the 'regex' matcher, I don't see why it wouldn't a second time.
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.

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.

[...]

> OK, I read that message after the other one. However, you message only
> makes sense if option (3) has already been eliminated. For the reasons
> above, I think option (3) should not be eliminated.

Since it never existed, I don't think we should worry about that. Before
we used the

	reopen_matcher->regex_matcher->subdriver_matcher

Which means that the only behaviour we had for reconnects was a slightly
less strict (without matching the Bus) matching than what we have now.

> Strict bus matching may (or may not) be desirable for behavior (1). In
> fact, I think it is not desirable, because even for a server, being
> able to move the UPS to different physical locations can be useful.

Yes, but no operator in his right mind would do this without seeing if
this worked while on site.

> If the user wants a specific bus, they can use the existing -x bus
> option, as has always been the case.

That would be cumbersome, since in that case you would first have to find
out where the UPS was connected before starting the driver. If you change
it, you need to both modify the -x bus option (more likely, 'ups.conf')
and then restart the driver. With the strict matching we have now, moving
the UPS to another port would just require a restart of the driver.

> Strict bus matching is irrelevant for behavior (2).

It can be used in the 'regex' expressions.

> Strict bus matching is a really *bad* idea for behavior (3). It
> basically means that no users, including desktop users, have the
> option to move their UPS to a different port any more.

It's not meant for desktop users, I think they would expect the driver to
find their UPS on any USB port they connect it to.

Best regards, Arjen