device filtering support

[Vitali Lovich]

I'm in agreement, except you may want to change the filtering independently of initialization; i.e. initialize, set filters, at some point later include devices into filter.  That's the reason it's a separate API call in my proposal.

-Vitali

On Feb 4, 2012, at 7:04 AM, Segher Boessenkool wrote:

> Hi guys,
> 
> It seems there are a few separate issues here.  Let me try to
> summarise and untangle it a bit, and propose a few things.
> 
> First, there is "enumeration".  In the context of USB, this is
> often understood to mean walking the bus, sending lots of packets.
> We do not want that, that is the kernel's job, not ours.  The only
> thing libusbx should do is ask the OS "what devices are there?",
> and get some list of identifying information for those devices from
> that.  This might or might not contain some descriptors; it is hard
> to imagine an OS that does not at least give us VID/PID for the
> devices, for example.
> 
> With hotplug (and hot unplug), all we need to immediately handle
> from the OS is again such a device handle ("minimal identifying
> information").
> 
> I understand the libusb core wants to keep all kinds of other info
> cached; we should change that to not ask for that information until
> it is actually needed.  And most of that information should be
> cached, not asked for every time!
> 
> If there is anything in our API that requires us to ask the OS for
> lots more (expensive) information than what is actually used, then
> we need to change things there (add a new cheaper API).  But I've
> seen no evidence for that yet luckily.
> 
> Then, filtering.  There are two aspects to filtering: it can reduce
> the amount of communication between libusbx and the OS (if the OS's
> interfaces allow for that); and it can let the user of the library
> say up front what devices it cares for (so we don't bother it with
> uninteresting devices).
> 
> This can potentially reduce the boilerplate code somewhat, too; it
> isn't so great that every program using libusbx has to do the whole
> dance with libusb_get_device_list() etc. (or use
> libusb_open_device_with_vid_pid() which is completely inadequate
> for anything but toy programs).
> 
> We could add a get_device_list_with_filter() thing; that reduces
> the OS communication, but not the boilerplate.  We could do an
> open_nth_device_with_filter() thing, but that is not ideal if you
> actually want to filter on more things.  It also doesn't help
> listing the devices.
> 
> I propose we do a libusb_init_with_filter() instead; what it should
> do is completely ignore (as far as the user of the library is
> concerned, and as much as possible internally as well) all devices
> that the filter doesn't match.
> 
> I don't have a strong opinion what a filter should look like, except
> it should be *simple*, so the filters people actually use can map
> to the filters the OS let's you filter by in its API.  I would avoid
> "deny" filters unless they are really really useful, since a) again,
> OSes do not give you those, and b) they are expensive (a list of
> allow/deny requires you to walk the whole list always, instead of
> using a hash or whatever).  So maybe just a list of accepted VID/PID,
> and classcode perhaps.  I dunno, let's experiment, and/or investigate
> what real programs want to use.
> 
> 
> Segher
>