device filtering support

[Pete Batard]

[this was sent to Vitali alone, and should have been sent to the list]

On 2012.02.03 18:47, Vitali Lovich wrote:
> I'm going to have to side with Travis - spawning a secondary process seems unnecessary&  wasteful.  Maybe if libusb applications were likely to run simultaneously with a lot of other libusb applications it might make sense (&  even then not so much).  Is there really something wrong with caching the descriptors within the Windows backend, unless the driver already does it on our behalf (i.e. libusb0/libusbk)?  We can also throw away most of the cached information as soon as the device reference is released so there should be any significant long-term memory bloat.

The problem is not with caching. Just like with a separate process, we
can do all the caching we want within a single app (and libusb already
requires us to cache the descriptors when we do enum). The problem is
that we can't enumerate hubs and composite devices without issuing
requests, so every time you start anew  libusbx process, you get
requests on the bus that will come pollute other libusbx apps.

Travis' approach to alleviate that is to drop much of the libusb enum
tree, and just enumerate the devices that an app explictly requests
(filtering). However this means that any libusbx app on Windows needs to
know exactly what device it wants to access beforehand, and it will not
be able to discover others.

I find this extremely limited especially when I very much see a way to
do otherwise.

But let me also tell you a story about "bat shit crazy" ideas.

In the early sixties, when NASA was trying to devise the best way to
send a man to the Moon, someone proposed the idea of using Lunar Orbit
Rendez-Vous as the most efficient way to achieve that goal. And every
singe person at NASA who was presented with the idea thought it was "bat
shit crazy". I mean, the idea of using staged rockets (creating multiple
threads), sure, it makes sense because it's easy to implement to save
resources, but using two independent spacecrafts (2 processes), you
gotta be crazy! You're going to multiply complexity, add extra points of
failure, and you'll need to devise communication and rendez-vous
techniques between the spacecrafts - there's no way that's gonna fly.

Wanna guess how the US ultimately went to the Moon?

Well, while we're not trying to go to the Moon, I can't help but see
some analogy here, since avoidance of unnecessary duplication should be
one of our goals. And the thing is we pretty much already have all the
tools we need to achieve that. Moreover, at least on Windows, I don't
think we can avoid having a separate thread for hotplug (we need to
receive Windows events), so we already need to get at least half way
there. The logical extension then is to go the full way and avoid all
this constant enum duplication from libusb apps while we're at it.

Now, If we want to avoid a fork or something that is going to end up
duplicating parts of the original app we don't need (and I think we do)
compiling, embedding running and communicating with an independent
process from within a lib is also not something I see as a problem at
least on Windows. I'm already doing that with libwdi, and it's going to
get even better with the next version since I'm gonna ditch my existing
stopgap embedder in favour of the much better bin2coff [1] (which can be
cross-compiled as well). I think the GNU binutils also make the process
of embedding random data quite straightforward for elf. So spawning a
separate process for enum = lot of copy/paste of tried and tested
elements and hardly a major hurdle.

Which leaves most of the work into taking care of details such as
communication, logging redirection, etc... => nothing that strikes me as
particularly difficult.

So, at least on Windows, I don't see spawning a process for a cached
enum as big deal, especially as we will already need to create a thread
to do part of that for hotplug, and if it alleviates the need to
introduce filtering as well as resource duplication across apps, it
might be worth having a closer look at the idea before dismissing
wholesale as either "bat shit crazy" or not worth the effort.

Regards,

/Pete
[1] http://pete.akeo.ie/2011/11/bin2coff.html