device filtering support

[Pete Batard]

[reordered to remove top-posting - I'd prefer if top-posting was avoided 
on this list, as I personally find it more difficult to read replies then]

On 2012.02.03 08:43, Vitali Lovich wrote:
 >>> Currently libusb-1.0 implementations enumerate all USB
 >>> device on all platforms which is quite an expensive operation,
 >>> especially under Windows. So this makes filtering during
 >>> enumeration process a desirable feature.
 >>>
> I disagree that I see a lot of *NIXisms in the API insofar as
 > the fact that Windows doesn't expose a user-space API for USB
 > (i.e. you have no choice but to write a kernel driver).  Both
 > OSX&  Linux provide a user-space mechanism.  I don't see that
 > as Windows taking a different approach but more that they're
 > just behind API-wise with what the industry tends to do.

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.

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.

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.

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.

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.

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

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.

Regards,

/Pete