device filtering support

[Vitali Lovich]

On Feb 5, 2012, at 1:27 PM, Pete Batard wrote:

> On 2012.02.05 20:22, Vitali Lovich wrote:
>> &  if it's in the middle of being communicated with?
> 
> It never is if it uses pipes. Either a full message went out or it didn't.
Yes, but let's say application 1 is communicating with the backend service. application 2 starts up & kills the backend service because it has a newer version.  obviously you've just broken the ability for application 1 to continue working.  That's what I'm saying.

> App asks the process for enum data and waits for it. If it doesn't receive anything it tries again.
How does it try again if the process it was talking to went away?

> There's no acking (because there's no need - it's not like we're going to have to query enum data for transfers, or even to re-open a device that was previously open). And yeah, I thought about re spawning the process and detecting whether that's needed or not, which isn't that big a deal either.
> 
>> seriously, the complexity of this is not worth the *perceived* benefit,
> 
> I'd turn that around with "the complexity you guys *perceive* for this thing is leaps and bounds beyond what it would most likely be". Be it with shared memory or interlocking, you seem adamant at making it _look_ more complex than it really needs.
> Excuse me for still respectfully disagreeing, since I actually went through an actual not too dissimilar exercise.
The point is the complexity is greater than the complexity of not doing it & solving it within libusb.  The other thing to note is that you solved it within libwdi (which actually required this kind of solution because of UAC) & libwdi has a completely different usage (i.e. 1 spawned process per libwdi instance - it's not shared among several processes).  I have actually done this type of thing as well & it's never as straight-forward as you would like, even with a static API.

>> especially since you have yet to demonstrate an actual problem that this solves.
> 
> The thing is, I don't really care about the problem that it solves.
Then you're just engineering a solution without having a good grasp of what you're trying to solve.
> 
> If Travis and Xiaofan weren't complaining about it, as well as threatening to deconstruct the generic enum we have as a result, I wouldn't give much of a damn about potential bus pollution. In fact, I probably started by downplaying the problem the first time we had this conversation privately.
The generic enum will not go away.  I understand part of it; it's completely pointless to enumerate devices you can never use (since they don't have a compatible driver).  However, the counter-argument is simple; for diagnostic purposes it's very helpful to print out the device topology (e.g. device A does not work with hubs).

> But Travis and Xiaofan are very concerned by it, therefore I am trying to look for a solution that satisfies them without removing some of the features that I want libsub(x) to provide.
Again, the first step is to prove the problem exists & understand it.
> 
> Now, if everybody but Travis and Xiaofan say: "this is a non issue", that's absolutely fine with me.
It's a non-issue as far as I'm concerned (until it's demonstrably not).

>> or what if the older one has to be used for another libusb application? you can't just kill it.
> 
> I very much can. Just like you replace a library in system32 with a newer one (not the part about doing it when an app is running, though I think Windows has mechanisms to let you do just that).
Again, you're missing the point; app1 uses backendv1, app2 uses backendv2.  Both are running at the same time.  You can't just go kill it.

> We can very much afford the delay of a respawn on enum, because we only need it the first time we want to gain access to a device, and can afford a wait there. You guys seem to think that the process an extension of the app, whereas it very much isn't, and no resources are shared whatsoever. The only thing that exists within apps are independent copies of the enum data from the enum process, copies that meet a specific API which we're not going to change from one year to the next because there's actually not much to provide in terms of enum that isn't well understood right now.
> Unless we change APIs, the data returned by an older process will be exactly the same as the data returned by a newer one. And we can of course create a process that returns data according to a specific API version if it ever changes (providing am API version during the request is something I'd implement by default actually)
So that means that once app2 is running, app1 could never run?
> 
>> you can't know what the compatibility matrix is unless you maintain 1 manually&  that's not a feasible solution.
> 
> Do we maintain a compatibility matrix for libusb?
What I meant by that is that you'd have to maintain a compatibility matrix of which versions are safe to kill (i.e. the new version is a strict backwards-compatible superset) & which ones aren't (i.e. must be able to run co-operatively with an older version).  The other approach is that every new backend version is it's own process & rendevouz works magically* in a version-safe manner, but that essentially gets us back to the original problem with multiple processes doing this.

*magically in the sense that everything just works, not in the sense that it's not possible
> 
> Seriously, just how complex do you think this process needs to be?
> 
> It would just feed enum data to apps. All it requires is make the private part of our OS specific enum data part of our API (a "private part" of the API if you will). Last time I checked, we only added new attributes to this private data - we didn't remove or change what was already existing. And very very infrequently. That is the _only_ part that needs to be common between the apps and the enum process (apart from hotplug events, but do we also expect to reshuffle our event mechanism every Tuesday?).
> 
>> Relying on static APIs is great up until they need a change,&  then you're up a creek without a paddle.
> 
> See above.
> 
>> If you had some kind of flexible IPC mechanism (i.e. thrift, protocol buffers, json) etc, that might work, but that's adding an unnecessary external dependency.
> 
> Unneeded. It should be a lot simpler than you anticipate, therefore we would never need that amount of complexity.
> 
>> I'm sorry, but I still fail to see the value of this whole approach.
> 
> I see an optimized way to provide enum data and avoid duplicates. And especially, I don't see a _proper_ implementation of the process being that complex, else I wouldn't propose it. Can't say for sure unless I go through an actual implementation, but everything I've seen so far tells me it's a lot less complex than everybody else has been trying to imply so far. Moreover, I've had a few months to think about it, since Travis, Xiaofan and I started this conversation quite some time ago, and I very much did contemplate the process approach on regular occasions.
> 
>> I don't see the potential for interference with other applications that you do
> 
> I don't really see it either, which is something I apparently haven't made clear, but Travis and Xiaofan seem to see it.
> 
> But it's not because I only see something as a limited potential issue that I'm not going to try solving it, especially when others insist that it needs solving (and I see other benefits in doing so, such as a better refactoring of hotplug and avoidance of unnecessary re-enumeration).
One factor you should keep in mind: P(> 1 simultaneous libusb application running on windows) ~= 0, so I question what it is the separate process would even solve.
> 
> Regards,
> 
> /Pete
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx