device filtering support

[Pete Batard]

On 4 February 2012 16:37, Michael Plante <michael.plante at gmail.com> wrote:
>
> Pete Batard wrote:
> >> we may have to spawn a standalone process
>
> Let's try to avoid this, if we can, regardless of the reason (hotplug,
> filtering, or some completely unrelated reason that comes up in a year).
> That is very heavy-weight and I think against the philosophy of libusb;
> threads I can accept, processes not so much.  Putting on my Windows end-user
> hat, I hate having to decide whether to kill processes or not.  If we wind
> up duplicating effort within each libusb-using process on each hotplug
> event, that seems a fair trade to me, and it sounds to me like you're saying
> it's still better than a full enum.


Well, the issue I am trying to solve is that:
- To get the data that libusb requires to build the enum info it
presents to apps (bus, etc.) using established Windows APIs, we have
to issue am ioctl to the hubs we meet. There's currently no other
official API that I know of that can provide us with the information
we need. There's a possibility that we may be able to hack into the
registry to reconstruct this data, but last time I tried to do
something like this, Tim was adamant that it was too dangerous in
terms of portability. Also, since Windows does its darnest to hide USB
concepts such as bus topology, I have doubts as to whether we can find
the data we need in the registry. Moreover, if we start getting some
data from the registry, we might as well get ALL our data this way and
drop the uses of Windows APIs, as our enum _will_ be a lot more
efficient this way. The use of official APIs is the reason we have to
do some many passes on Windows, in order to be able to present
something that includes the basic elements of USB topology that libusb
requires.
- If we keep using the official Windows APIs, then our only option is
to add a layer that does some caching of the hub data and avoids
re-querying. Obviously, this needs to go in par with hotplug, and we
already have a thread there, which needs to re-enumerate (we have
additional constraints there), so at the very least the best approach
looks like adding our caching operations in this thread, along with
enum. At this stage we should be able to have a threaded solution that
does the querying we need once per app.
- Travis indicated that he sees querying hubs as unacceptable, even if
we do it once per app, as it could come pollute transfers from
existing ones. The only solution I see to meet his request then is to
have a separate process. Otherwise, we're going to have to go with
filtering that drops hubs and is unable to provide some of the key
concepts such as topology. As I don't see the process solution as that
demanding, and I think it would actually benefit other platforms, this
is the options that looks best to me. It avoids building the same list
over and over, which libusb currently does, as this is done for each
open.

So my position is:
- The only way I currently see to go with filtering, as Travis
suggest, is if we accept dropping key USB concepts such as the ability
to use libusb to produce a complete USB device topology or provide bus
info.
- Otherwise, we have to rework our enum in some way, at the very least
on Windows, and the only option I see as not introducing additional
limitations then would require the spawning of a separate process for
enum.

This being said, trying to figure out this whole thing before we know
where we are headed with hoptplug seems a bit foolish, which is why
I'd rather wait until we're there to start devising how we may improve
enum. Since I actually went the trouble of implementing hotplug on
Windows, in a libusb compatible manner, I do of course have some ideas
of what our constraints might be as well as where we might want to go
from here, and that's what I've tried to let you guys know. But unless
we're all there (i.e. with some hotplug code integrated, which may or
may not be similar to the one I have), I think it's a bit premature to
try to decide how exactly we should do it.

I also don't have much of a problem with Segher's suggestion of having
additonal API calls for filtered, though I think the filters Travis
would like to apply would be Windows specific GUIDs related to devices
and drivers rather than general USB items such as VID:PID.

Regards,

/Pete