device filtering support

[Xiaofan Chen]

On Wed, Feb 8, 2012 at 8:36 AM, Segher Boessenkool
<segher at kernel.crashing.org> wrote:
>>>> Right now I am more inclined to Segher's compromised
>>>> proposal of give user the option of using filter to reduce
>>>> unnecessary traffic (please refer to my previous reply).
>>>
>>> Yeah, I'm pretty sure it's possible to convert VID/PID to GUIDs, or
>>> to determine the VID/PID without actually querying the device;
>>> after all, the VID & PID are encoded in the device instance path.
>>
>> My thought is that GUID can be a filter for Windows.
>
> That will make your code Windows-only.  If you also do not implement
> the VID/PID filter, you cannot build any code written on another
> platform; if you do implement it but stub it out, it will run but
> just as insanely slow as it does now; and if you have the VID/PID
> filter implemented in such a way that it does in fact reduce traffic
> as it should, then what do you need a filter on GUID for?
>
> I see no up side to this idea, sorry.

I was thinking the same as you that the user should know
the VID/PIDs of interests beforehand and therefore
VID/PID filtering should be good enough, for all platforms.

But then the desire from Hans is that he wants to filter
on device class, allow users to plug-in any unknown
device and still the app should work. That can be done
under Linux and probably Mac OS X (if the OS X
kernel does not claim the device), but difficult under
Windows unless using the libusb0.sys in class filter
mode (which is unproven in terms of stability yet).
The second best thing under Windows is to do GUID
filtering.

I understand that VID/PID filtering itself can help
a lot but it may not cover Hans' use case.

-- 
Xiaofan