device filtering support

[Michael Plante]

Xiaofan Chen wrote:
>> On Sun, Feb 5, 2012 at 8:34 AM, Michael Plante <michael.plante at gmail.com>
wrote:
>> > Pete Batard wrote:
>> >>>> Please define disruptive.  If you just mean "excessive", then I
>> >>>> would say that's redundant (just optimization) and we should just
>> >>>> go with threads.  If you mean "it breaks things", then I'd say we
>> >>>> need to rethink this whole thing.  Did I miss a third potential
>> >>>> meaning for "disruptive"?
>> >>>>
>> >>> OK. Disruptive, in the way I understand Travis' concern, is:
>> >>> - libusbx (or non libusbx) app 1 is doing isochronous or bandwidth
>> >>> heavy transfers on the bus
>> >>> - libusbx app 2 is either launched or does something (open) that
>> >>> produces an enum. With the current Windows enum process, this
>> >>> results in hubs being queried and potential packet dropped for app 1.
>> >>>
>> >> With the current Windows enum process, this results in
>> >> hubs being queried and potential packet dropped for app 1.
>> >
>> > Ok, I understand, but I think that that is tolerable and most users
need to
>> > understand that can happen anyway with USB.  Don't go doing other
things
>> > when you expect time-sensitive operations to complete successfully
(such as
>> > watching video).  And if you do, try again.  Give people credit.
 They'll
>> > learn.  This is less bad than what I thought you were saying, so I
still
>> > think threads are the way to go.
>>
>> It is worse than you think it is.
>>
>> Take note app1 and app2 operate on different device. And it is not
>> only isochronous transfer, it can affect other transfer type like
>> bulk transfer as well.

Yes, I realize that, and bulk transfers are retried anyway.  My point is
pretty general.  One thing I did not consider is time-shared/multiuser
machines, but users do not usually hotplug on those, or even have physical
access.


>> app1 can be a non-libusbx application operating on a device which
>> the innocent Joe user think that app2 should have nothing to do with.

Irrelevant.  If "Joe user" cannot put two and two together that he just
plugged something in and his video started lagging and "oh I guess I
shouldn't do that again", he should go buy a typewriter.


>> So do you think this is just plain "excessive" and thus only need
>> "optimization" or it "break things" and need "rethink this whole thing"?

I would argue that the cure is worse than the disease.  I think that if/when
this happens, the traffic is in fact excessive, and that while the
optimization Pete suggests might solve the problem, it creates bigger
problems.  While this excessiveness breaks things, the proper solution is
"don't do that".  Sort of like learning not to pull the power plug from your
computer while it's running.


>> If we go with Pete's idea, it could be implemented as a system service
>> under Windows.

That is not at all what he suggested, but it is a slight improvement since
it can be shut down non-forcibly without writing any code.


>> Does the system service idea solve the versioning issue?

No.  Different applications were written at different times, and may expect
different protocol versions.  They may even come to RELY on certain bugs to
continue to exist.  Even static linking fails to rescue us here, because
we're now talking about a process.

Regards,
Michael