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

[Peter Selinger]

Arjen de Korte wrote:
> 
> > I am not sure how the kernel or HAL are supposed to distinguish devices
> > that we can't. They see the same information that our driver sees.
> 
> They don't have to. They will only match a VID:PID combination, see that
> (for example) the usbhid_ups driver needs to be started and will start it.
> The thing the kernel (HAL) can do (and we can't) is to pass the pysical
> location of that particular USB device to it on startup, so (for Linux) it
> will pass the 'bus' and (enumerated) 'dev' to the driver. If the driver
> needs to reconnect, it would only try this combination and won't try any
> other usb devices.
> 
> The reason why this will work (and we can't use this now), is that when a
> user pulls the USB plug, the driver will be sent a SIGTERM, so the driver
> will only be running as long as the device is attached. If you later
> replug it (possibly in a different physical USB port), the whole process
> will just start over again. As you see in the above, the driver never
> needs to match the device, that is handled by the kernel (HAL), so there
> is no problem with connecting different devices that can't be
> distinguished from one another. This is not needed, since the 'bus' and
> 'dev' are guaranteed to be unique on a system.

This does not solve the problem where multiple identical UPS power
different loads. However, that latter problem will probably never be
solved anyway, except by the (last-resort) -x bus option. 
 
> Therefor, with HAL we would be relieved of both the problems with matching
> devices that look identical (for instance, some Tripplite HID devices) and
> also never run the risk of connecting to the wrong device when
> reconnecting.

Yes, but the cost is that the monitor may have no idea what device it
is monitoring.

> We could keep the subdriver matching in usbhid_ups, but
> could also delegate this to HAL and just create separate binaries for the
> different drivers when HAL is used. I think the latter is a more elegant
> solution, but we could easily accomplish this by some strategic #ifdef's,
> so that we can still build the 'classic' usbhid-ups if no HAL support is
> present.

Or add a -x subdriver option so that HAL can start the existing driver
as if it were a specialized one. 

-- Peter