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

[Peter Selinger]

Arjen de Korte wrote:
> 
> [...]
> 
> > 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).
> 
> I think we're trying to solve the problems of USB-to-serial UPS'es in the
> wrong way here. This whole problem would not exist if the kernel would
> auto detect the USB-to-serial converters in these devices and add a
> /dev/ttyUSBx port (or something like that), so that existing drivers could
> connect to it. Apparently, this doesn't happen right now (otherwise we
> wouldn't be seeing all these problems), so we need a workaround here. I
> think we should try to work in the direction of adding /dev/ttyUSBx ports
> for these devices, rather than trying to do this in each individual
> driver.

I disagree. There is no generally accepted USB-to-serial standard that
these devices follow. Each manufacturer implements their own,
completely ad-hoc, hack by which to port their proprietary serial
protocol to USB. There is no general principle at work that could be
explointed by a general-purpose /dev/ttyUSBx device. 

The only way to communicate with one of these devices is to write a
device-specific *driver*. And this is exactly what we are doing.

Also, it is not just that their protocol is simulating a serial
port. At least in megatec_usb, it's more complicated than that -
specific UPS commands are mapped to specific methods of sending and
retrieving.
 
> > 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).
> 
> I don't like this. Setting 'port = auto' (even when it doesn't really
> matter what is used) already confuses the heck out of some people, so this
> is not going to improve things.

Well, most users are confused because they want to set the port to
something that identifies a device. My above proposal does exactly
that. 

But I agree that it would be better to have -x variables for this
purpose though.

-- Peter