device filtering support

[Xiaofan Chen]

On Fri, Feb 3, 2012 at 7:27 PM, Pete Batard <pete at akeo.ie> wrote:
> I kind of know where Xiaofan is coming from, as this is something we already
> privately discussed, along with Travis. The problem is that currently,
> whenever we reenumerate on Windows, queries are being sent to hubs and other
> devices and cannot be avoided due to Windows API limitation. Obviously,
> queries that can pollute the bus should be avoided. Enum is also quite
> resource consuming, and the current libusb seems to enumerate a lot more
> often than it really should (if you issue multiple open() in a row on the
> same device, they all result in a full USB enum)
>
> Xiaofan and Travis, as well as possibly Tim, seem to think that our only
> option on Windows then is not to list everything during enum  (ignore hubs,
> and other components that require queries, such as composite parent devices
> as well, if I'm not mistaken), but I very much disagree with that.

We think that is the easiest solution and it is the one method used
in libusb-win32 and libusbK. It serves the user quite well so far.

> IMO, the idea of providing a list of all USB devices known to the system is
> the right approach, and is what users of a generic USB library will expect.
> Why? Because our mandate is to translate as much of the features that the OS
> provides, into accessible userspace features. At anyone time, the OS is
> expected to know exactly which peripherals are plugged into a system, and be
> able to provide a complete list, so libusb should very much attempt to do
> the same, whether on Linux, OSX or Windows.

This is not a convincing reason at all.

I believe most of the use cases of libusb only cares about one or a few
particular device, with known VID/PIDs. Therefore I do not see the need
of enumerating all device.

Just another example, for hot plug event, do most users only
want to listen to the hot-plug event of interested device? Or do
they want to listen to all the hot-plug event of all USB device?

> Else, we'll need to devote a lot of effort educating our users, either
> through the API, or through actual documentation, on why libusb can't find
> their USB device and why it will require an additional step to do so. With a
> library that aims at being generic, I think it will be counter-intuitive for
> users and should be avoided.

You still need to tell the user to install supported driver (e.g.: WinUSB)
even if they can find the device. And in the case of Mac OS X, you
still need to tell them that they may need to write a code-less kext
in order to really talk to the device.

Enhanced ticket #67 (as per Pete's comment) may help though.
http://www.libusb.org/ticket/67

> This being said, Xiaofan is right that there is a problem that needs to be
> addressed on Windows. But my current view on this is that we will be in a
> much better position to address it once we have hotplug, and therefore
> should wait until then. From where I stand, the fundamental issue, really,
> is that due to its lack of hotplug, its Linux origins and possibly time
> constraints from the original libusb-1.0 developers, libusb heavily relies
> on enumerating whenever, and sees regular re-enumeration as a
> no-consequences acceptable behaviour. This may be true on Linux and OSX
> (though I seem to remember Nathan having issues with), but that is most
> definitely not the case on Windows.

I think Vitali sees the performance penalty under Mac OS X as well
and that is the origin of the filter idea.

On the other hand, I kind of understand that the current implementation
is based on the Linux behavior and that was what Daniel/Peter wanted.
So it is really difficult to change (not to be in libusb 1.0.10 anyway). That
is why I think that filter might help if we do not change the basic
implementation.

> If libusb has hotplug however, there's suddenly less of a requirement for
> libusb to ask the OS for a list of USB devices over and over again, as we
> should then be able to maintain a "permanent" internal list, that we update
> according to hotplug events. Now, if we want to push this idea to its
> logical conclusion and remove all unnecessary re-enum (which we very much
> want to do on Windows), we may have to spawn a standalone process for our
> very first enum, that all subsequent libusb processes can then query
> (daemon, service, but in userspace) and that would be killed on libusb_exit
> from the last libusb app currently running. It may add a bit of complexity,
> but it doesn't look that unachievable to me. I also see many advantages
> terms of avoiding duplicated resources and ensuring that libusb handles all
> of its hotplug events from a single location.

If that is the case (enumeration is only a one-time job during the startup,
subsequently only changes are monitored), then probably this is a solution
as well.

Does that mean filter is no longer really required in this case?

> Therefore, I don't think we are in such an impasse on Windows that we have
> no choice but to implement non-intuitive filtering.

If you are right, then this might be a compromise. I'd still like to hear
Travis' comments on this idea.

> But the other problem we have is that we have the following major items
> to address then:
>
> 1. hotplug
> 2. cross platform event handling
> 3. filter/enum overhaul
>
> and the implementation of each one is likely to heavily depend on the
> choices we make for the other two, which makes it more difficult to attempt
> to tackle each one in isolation. On the other hand, trying to tackle them
> all at once doesn't exactly strike me with a good approach either, because
> we may decide to go one route in the abstract, that we come to regret during
> actual implementation.

If we follow the simple enumeration strategy of libusb-win32/libusbK, then
I think 1 and 3 are simpler and 2 can be decoupled. 2 (cross platform
event handling) itself is a hot topic as well, especially for Windows.

But I understand where you come from.

> Thus I'd suggest we do it sequentially, in the order above, with the
> following amendments:
> 1. hotplug that doesn't rely on cross platform event handling (eg. using
> callbacks only, as with the Nokia proposal)
> 2. cross platform event handling and hotplug refactoring to leverage those
> 3. filter/enum overhaul and additional hotplug refactoring if needed
>
> Since we pretty much have a proposal for 1 for all platforms, it is the
> approach that makes most sense to me at the moment. As such, I would leave
> the decision on how we should approach filter/enum overhaul for after we see
> a bit clearer with the other two.
>

The strategy makes sense if your solution indeed can really remove the
un-necessary renumeration.

-- 
Xiaofan