[Nut-upsdev] Re: [nut-commits] svn commit r801 - in

[Peter Selinger]

Alexander I. Gordeev wrote:
> 
> On Sat, 17 Feb 2007 01:55:30 +0300, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> 
> > We still need to:
> >
> > * fix the device matching code, so that new users can experiment
> >   without having to write C code,
> >
> 
> Do you think that the current matching scheme of the usbhid-ups
> driver is suitable in our case? (I've looked at usbhid-ups because
> it is the only one having subdrivers.) I think not. We deal with
> several vendorids that do not actually belong to any vendor - 0x0001
> and 0xffff. It's possible that new devices will have different
> vendorids. So an end user should be able to take control over the
> matching process by "-x vendorid=<value>", right? This is not
> supported by the usbhid-ups matching scheme.

In usbhid-ups, device matching serves several different purposes. 

(1) To see which device the user wants to connect to, in case a single
    machine is connected to several different UPSs. This is important,
    because developers often have more than one UPS. It is also
    important for server-type installations with multiple UPS units.

(2) To decide which subdriver to use.

(3) To ensure that we are not connecting to any devices that are not
    UPSs (hubs, mice, toaster oven), unless specifically requested
    otherwise by the user.

As far as I see, all three concerns are also valid for megatec_usb.

(A) The default behavior should be to connect to the first device
found that is known to be supported (i.e., whose productid/vendorid is
in the list of subdrivers).

(B) However, *if* the user specifies either productid or vendorid,
then we should connect to the first device that matches the user
choice (even if it is not in the list of supported devices). This will
allow users of new devices to experiment without having to change the
source code. (Very important for daily support on the mailing list).

Behaviors (A) and (B) take care of concerns (1) and (3). 

Finally, the choice of (2) is easy in case (A), because we already
have a list mapping devices to subdrivers. In case of (B), if we match
a device that is in the list, then we should use that subdriver by
default, but the user must be able to override this. Finally, if we
match a device that is not in the list, we must choose a reasonable
default, and the user must definitely be able to override it. 

I thought about adding three options 
-x vendorid 
-x productid
-x subdriver
 
to implement this behavior. (One could also match by vendor name,
product name, or serial number as in usbhid-ups, or allow regular
expressions, but that is perhaps not a priority). 

The problem with this approach is that the variables need to be
declared in upsdrv_makevartable(), which is shared between the megatec
(serial) and megatec_usb drivers. So this part of the code would need
to be specialized somehow (move it to megatec_usb.c, and make a new
file megatec_serial.c, containing only serial-specific code).

Another option is to use the existing "port" variable, which is unused
in USB, so that the user would specify something like ffff:0001:ablerex,
which each ":" being optional, i.e., valid ports are:

1234                (vendorid only)
1234:5678           (vendorid and productid)
1234:5678:subdriver (vendorid, productid, and subdriver name)

The advantage is that it needs no special new options. The
disadvantage is limited flexibility for future extensions (match by
serial number etc).


> We simply cannot determine whether the current device is supported
> or not having only vendorid and productid. There is a solution
> however. We don't need to claim the device to use
> 'get_string_simple' function, am I right? Then we can retrieve
> several important string descriptors to examine them. This solution
> looks pretty ugly, I think. It will also need many changes in shared
> files, which is the worst.

I don't think we should try to probe unknown devices to see if they
are supported. The choice should simply be as outlined above: only
known devices are automatically supported; other devices are connected
to if the user specifies it explicitly.

-- Peter