device filtering support

[Vitali Lovich]

It's a start.  The OSX stuff isn't optimal either - I think you can actually specify the device requirements within a dictionary when you ask to get an iterator.  I did notice a huge performance impact on OSX even without the filtering via IOKit - I haven't looked at Windows all that much from a performance perspective to be honest.

This is meant to have a two-fold benefit:
	1. Do the filtering as early as possible so as to reduce the overhead
	2.  Reduce the amount of boilerplate code necessary to get a working libusb application written

#2 IMHO is the far more important use-case - #1 can always be fixed later on as hotspot analysis dictates (especially if we don't code ourselves into a corner, which I don't feel this patch does).  #2 is a users first experience with the library - if it makes it painless to just get off the ground & go, then I think that's great.

That being said, I'm really open to having someone provides optimizations to the Windows backend since that's not my forte; I'll take a look at further improving the OSX backend.

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.

-Vitali

On Feb 3, 2012, at 12:19 AM, Xiaofan Chen wrote:

> On Wed, Feb 1, 2012 at 4:46 PM, Xiaofan Chen <xiaofanc at gmail.com> wrote:
>> Take note we are talking about filtering during enumeration
>> (getting the device list), not after the enumeration. You can
>> filter many things after getting the device list.
>> 
>> 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.
>> 
>> libusb-win32/libusbK use different mechanisms which makes
>> the enumeration faster since we mainly deal with specific
>> devices and only enumerate the device with supported drivers.
>> 
> 
> Looking at Vitali's patch, I am not so sure if this will make
> the enumeration issues under Windows much better or not.
> 
> There is a fundamental problem here as Tim Roberts mentioned
> here.
> http://libusb.6.n5.nabble.com/libusb-windows-devices-only-detected-in-late-pass-ignoring-tp4463538p4521855.html
> 
> +++++++++++++++++++++++++++++++++++++++++++++
> However, the bigger problem is that we are trying to shove a square peg
> into a round hole.  Libusb undeniably has a Linux heritage, and its
> philosophy is strongly oriented towards the Linux way of doing things,
> which are very different from the world of Windows devices.  The concept
> of "show me every device in the system so I can find mine," which is
> found in the driver stack for virtually every Linux bus type, is foreign
> to Windows.  It does not scale well.  It requires each
> driver/application to have knowledge of the internal workings of its bus
> -- information that it should not need to have.  Windows abstracts all
> that, so that a driver merely says "this is my device", and it's up to
> PnP and the Device Manager to do the searching and the matching, and the
> hotplug management.  We are battling that abstraction.
> 
> I'm not saying I have an answer.  There is an impedance mismatch here
> that is, in large part, unresolvable.  As long as libusb tries to
> pretend that it is offers the Linux philosophy on Windows, there will be
> ugliness underneath, and it's not going to get better.
> +++++++++++++++++++++++++++++++++++++++++
> 
> I am hoping that the filter mechanism will help to minimize the
> impact on the bus for the current libusb-1.0 Windows device
> list enumeration implementation. But it might be not that easy.
> 
> The whole thread is quite long and there are quite some
> questions unanswered in that thread. Maybe it is a good
> time to discuss this issue again but I understand to bring
> up the issue may well open a new can of worm...
> http://libusb.6.n5.nabble.com/libusb-windows-devices-only-detected-in-late-pass-ignoring-td4463538.html
> 
> 
> -- 
> Xiaofan
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx