On Friday 06 October 2006 8:51 pm, Christopher "Monty" Montgomery wrote: > On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote: > > On Friday 06 October 2006 7:22 pm, Christopher "Monty" Montgomery wrote: > > > > Except that your comment is incorrect in both content and intent. The > > > whole point is that the bandwidth *is* still there and *will* be > > > available, by design. > > > > Nope. That's not the policy Linux uses. Alan has pointed that out, > > and I've pointed that out. You should listen to us on that issue. > > I will point out I was documenting what the code actually did, and > what the code actually asserted.
Nope ... current kernel plus patch #1 obeys the comment I showed. > If the code is wrong, the code and comment both have to change--- not > just the comment :-) > > However, it is the case that if the ehci_iso_stream struct is still > around, so is its bandwidth, even in the case where the stream is > released when the last URB completes. One will not exist without the > other once the first URB is submitted. When the stream is freed, the > bandwidth _will_ be released. There is no maybe involved. Erm, no. No. No. No. No. No, No, No, No. NO! No. Nono. Nonononono. That is not the result of applying your patch #1. > > You are suggesting a model where as soon as an endpoint gets enabled > > and used, it ties down bandwidth virtually forever. This creates > > nastily mysterious fault modes, like: because several days ago one > > application may have sent URBs to ten different ISO endpoints, today > > no application can use any more ISO endpoints ... because those > > bandwidth reservations never got canceled. > > I woudl assert that if the fds are open, the bandwidth should still be > reserved. Again, you're mixing up levels. An FD is at least two layers above the place where the bandwidth reservation policy is implemented. > But that's a theoretical assertion and one I'm not going to > stick to or argue for. I do argue against the opposite extreme-- > where any application or driver misstep gets bandwidth revoked and you > may not be able to get it back. Driver missteps like "(*(int *)0) = 23" do bad things too. The policy is that driver "missteps" are bugs that should get fixed. So far you haven't convinced anyone that the usbcore (and hcd) policy is in need of changing ... please stop arguing that point, unless you come up with a new argument that's not based on misunderstanding!! > That is currently the default case if the higher-level driver does not > explicitly stuff buffers (ie, do the rok to change the default case). Erm, no it isn't. The problem you are describing is simply that a upper level driver (maybe not even the highest level one, e.g. not ALSA but a driver between that and USB) is doing the wrong thing. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
