device filtering support

[Vitali Lovich]

This API was never intended to be perfect for all use-cases or even to be generic.  I believe it solves the problem that almost everyone encounters (and definitely everyone writing user-space drivers or quick & dirty test code), which is wanting to access a particular product.  Further filtering of the device based of device class, interfaces, endpoints, etc is an application-level problem & not necessarily something that everyone will care about.

Additionally, I wanted to expose a minimal interface for several reasons:
1) Not all information is available extremely early on; I want to make sure that the filtering can be performed as early in the stack as possible.
2) The filtering engine could get complex; I'd rather get a quick & dirty solution in that solves a major problem & then solve it with a more elegant solution with a better understanding of requirements*.  VID/PID is useful for everyone.  Device class I think is less-so; are there any products that have different device classes exposed & where applications only support one of them?  In fact, looking at the devices on my machine, the device class/subclass is completely un-interesting & provides no information; the more interesting information resides in the interface descriptors, which as I mention in 1) is not something I want to get into right now as it involves potentially expensive operations (i.e. opening the device & reading the descriptors) & could only happen later in the stack (i.e. after the device has already been initialized).
3) The filtering engine you point to has serious API leakage problems from a library perspective (e.g. structs expose their data structures), which is precisely why I did just vid/pid the way it is because a more flexible API can be added later without breaking ABI or API.  Designing this properly will take time & again - the vid/pid filtering is just so damn useful. 

I think the filtering engine should actually be more of a classifier engine.  For instance, instead of filtering out devices altogether, I can register with the hotplug system: devices matching rules in X use callbacks A, devices matching rules in Y use callbacks B.  Then filtering is just a by-product of specifying NULL callbacks for a specific set of rules.  But again, I want to minimize the amount of side-effects that using this would have (i.e. unexpected usb traffic generated).

-Vitali

On Jan 30, 2012, at 11:50 PM, Hans de Goede wrote:

> Hi,
> 
> On 01/31/2012 07:06 AM, Vitali Lovich wrote:
>> https://github.com/vlovich/libusb/tree/filter_support feature rebase on top of rc3
>> 
>> Request for review.  Verified works on Linux.  Pretty sure that it works on OSX&  Windows as those code paths are even simpler.  I'm planning for this to go into the first forked release of libusbx (i.e. not 1.0.9).  This can have significant benefit in terms of CPU usage since it avoids unnecessary allocations&  usb querying if the device is of no interest to upper layers.  It also simplifies a lot of user code since they typically will filter for a specific vid/pid from the list anyways.
>> 
>> libusb_filter_vid_pid(libusb_context *ctx, int *vids, int *pids, int nfilters);
>> 
> 
> I hate to throw a spanner in the works, but as someone who has very recently added
> very similar code to his own code (to filter out devices from redirection to a virtual
> machine) I think that this API is insufficient.
> 
> The user may also want to filter by device class and/or revision, and since you allow
> wildcards in your filter rules, you also need to be able to indicate if a rule is
> a deny or allow rule, so that you can say for example:
> 
> vid  pid  allow/deny
> 1234 2345 deny
> 1234 9876 deny
> 1234 Any  allow
> 
> And something like the pcscd/lite ccid driver wants to be able to say:
> 
> class  vid  pid  allow/deny
> ccid   4567 1234 deny
> ccid   Any  Any  allow
> Any    Any  Any  deny
> 
> Note that class checking is non trivial, since class is usually per
> interface and a device may have multiple interfaces.
> 
> So we probably need some flags for the filter code, to specify whether
> the class check is done on all interfaces (so a combined mass-storage
> / ccid device would be filtered out by the above filter), or if it
> matches if any interface matches (making a theoretical combined mass-storage
> / ccid device be not filtered out).
> 
> See here for what I came up with for my usbredirection code, esp. also
> the part about how my code does class based filtering:
> http://cgit.freedesktop.org/~jwrdegoede/usbredir/tree/usbredirparser/usbredirfilter.h
> 
> Note I'm not saying this is perfect and should be copied 1 on 1, but hopefully
> it is helpful.
> 
> Regards,
> 
> Hans
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx