device filtering support

[Xiaofan Chen]

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.

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.

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


-- 
Xiaofan