> Ok, I see your distinction between endpoint and URB. > > It unfortunately still doesn't work.
Oh yes it does ... :) >>When that second driver submits its urb, assuming that needs >>to reserve some bandwidth, the "is it available" logic will be >>accounting for the first endpoint's bandwidth consumption. >>Because it would never have been released. > > > Yes it will be released. There are no URB's outstanding for that > endpoint. But the endpoint was still busy, so bandwidth wasn't released. Go back and reread what I wrote. Soon I'll get _really_ tired of repeating that part of what I've been saying all along. When that happens, you can just assume it still stays true. > Regardless, explaining this race condition to you is moot, because from > a conceptual level, your implementation is still not reserving the > bandwidth. It most certainly is, although you don't want to admit it. What you're talking about is splitting apart two aspects of a reservation: making it, and using it. I've been talking about the latter aspect. (A "wildlife reserve" surely had wildlife before it some planning commission labeled it as a reserve.) > I'll give you a *completely* seperate example: > > HID devices. They don't use their interrupt out pipe often, but the > bandwidth needs to be reserved so they are never denied it. Such a device _could_ easily reserve bandwidth by keeping a transfer queued at all times -- with no new APIs needed -- if it ever notices bandwidth shortage as a problem. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
