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

[Arjen de Korte]

> 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.

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. 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.

Best regards, Arjen