device filtering support

[Pete Batard]

On 2012.02.04 19:00, Michael Plante wrote:
> Pete Batard wrote:
>>> At this stage we should be able to have a threaded solution that
>>> does the querying we need once per app.
>
> Are you saying this will not work? ... see next point for why I think you
> MIGHT be saying that...

I would say that I'm saying it may not work, depending on what we see as 
acceptable behaviour of libusbx.

>>> - 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.
>
> If hubs becoming corrupted is why threading won't work, then we're dead in
> the water.

I'm not currently seeing hubs being corrupted, though I may misinterpret 
what you mean by that (or maybe you know something I don't). But I do 
see potentially disruptive traffic originating when starting a new 
libusbx app, if we go with the thread solution.
If people here says it's OK, then I'm fine with going with the threaded 
approach, but if not, I don't currently see much of an alternate way 
than spawn a process.

> I hate to break it to you, but libusbx is not the only game in
> town.  There is also proprietary software, as well as openusb or whatever
> it's called (I ignore those messages frankly).  And maybe libusb will copy
> your code too.  So I hope I'm misunderstanding and that you're merely trying
> to optimize, rather than saying that threading won't work at all.

I'm both trying to optimize and avoid potentially disruptive traffic.

> I'm actually really not all that concerned about hotplug or filtering right
> now; my concern is more long term and basic.  Here's my real point, which I
> wasn't clear enough about.  Say you have five horribly buggy libusbx-using
> programs on the system written by 5 developers.  We make libusbx perfectly
> clean, which is a chore unto itself.  That's not good enough.  I want those
> programs as isolated as possible, so when each dies its fiery death, it
> doesn't take the others down with it at the same time.

Which I don't see as a problem with a standalone process. Apps will just 
query that process, and the process will also occasionally send a 
message to apps that registered for hotplug, so, unless we do things 
poorly, and especially as the whole point is not to generate bus traffic 
except on hotplug, I don't exactly see how an app could cause that 
process to crash by asking "Hey, can you give me some <cached> libusbx 
data about device xyz?" or when receiving a ping about hotplug.

Then again, I haven't looked that closely on how this whole process 
should be implemented in practice, so there's the possibility it won't 
be that simple.

> Introducing shared
> resources and that kind of thing is bad -- we moved away from that when we
> ditched 3.1/9x, to speak loosely.

Which is why the resources wouldn't shared. Each app would ask for a 
copy of the libusbx enum data. Apps would not be able to update the data 
themselves.

> And while I said I'd try to offer time to
> help with integration, I didn't say I have time to help with a whole new
> interprocess communication design, which I forsee as being something of a
> whole new nightmare, if it's even possible to do right.

See the Lunar Orbit Rendezvous analogy... ;)

I'm not seeing it as that much of a nightmare for the time being (but 
again, I'm not looking at it in terms of having to implement it tomorrow).
Yes, it is more complex in a process than in a thread. But is it 
nightmarishly complex?

Regards,

/Pete