device filtering support

[Xiaofan Chen]

On Sun, Feb 5, 2012 at 9:45 AM, Michael Plante <michael.plante at gmail.com> wrote:
> Xiaofan Chen wrote:
>>> 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.

No he did not plugged anything. He is listening to music using
a USB Audio Device (USB Audio Speaker). And whenever he
runs another application (which depends on libusbx and operate on
a generic USB device) and suddenly finds that the audio get
distorted.

The user is smarter than the average Joe users, so he
moves his USB Audio device to a different root hub port,
still the problem exists. He gets annoyed.

I know this example may not be a very good one. But you
get the idea.

>>> 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.

I agree with you that Pete' cure is worse than the disease. But if we go
with the approach Travis is using in libusb-win32 and libusbK, app2 will
not disturb app1 at all.

On the other hand, I understand the desire to follow the Linux libusb's
idea of "query all USB device for information". In that case, libusbx
can not use the approach of libusbK. I was hoping Vitali's filter approach
can help to make things better.

>>> 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.

The problem is then the libusbx apps can not starts any more if
libusbx apps need to depend on the service.

>>> 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.

Ah, thanks for the explanation. This itself can be a very good argument
against Pete's idea. Thanks.

-- 
Xiaofan