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

[Arjen de Korte]

[...]

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

Indeed.

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

Not neccessarily. The user won't be able to specify a upsname anymore, but
there is no reason why these couldn't be unique. For instance, we could
create a name automatically based on VID:PID, bus and serial number for
instance. Granted, that will probably not be unique for devices that
violate the USB specification by not announcing a serial number and are
all connected on the same USB bus, but in many cases where it does (or
where there is only one device attached) this is sufficient. I don't think
the fact that there probably will be situations where this doesn't work,
means we should not do this at all.

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

That wouldn't be needed, HAL also provides the VID:PID combination. We
would only do this because the binaries might be a little smaller. They
wouldn't have to drag with them the subdrivers that don't get used anyway
(usbhid-ups is one of the biggest drivers we have now). We should only do
this, if the drivers are selected by HAL. For installations where the
driver would be selected by a human, having them all in one (big) driver
is more advantageous, as it eases the selection process.

Best regards, Arjen