Could not all these scenarios be handled the way you want them to with explicit queues (see my last post to the list)?
Regards Stephan -- Matthew Dharm wrote: > > On Thu, Jun 06, 2002 at 02:06:30PM -0700, David Brownell wrote: > > > I'd like to see all those URBs terminated immediately, but > > > I'm sure others would like to see them all executed as if nothing had > > > happened. > > > > I agree that it makes no sense to continue processing later URBs queued > > on that same endpoint. Similarly when the endpoint halts, or one URB > > is canceled. The transfer stream has been broken, and recovery needs > > to be done before the endpoint can be used again. Having some other > > URB queued (or not, in the non-queued case) doesn't change the need for > > that recovery before proceeding. > > Ah, and now the counter-example: > > Consider a usb-storage 'read' command. I now have 5 URBs queued on a > bulk-in endpoint to transfer the data. Behind that, I have a 6th URB which > is supposed to fetch the status. > > If the read fails due to short read, I still want the 6th URB to execute so > I can get the status. > > Yes, I could not queue that URB until after the transfer is completed, but > it would be more effecient (read: faster and lower CPU requirement) if I > could queue it ahead of time (or during the sequence of read-URBs for the > data). > > Realistically, I can come up with needs for both behaviors (kill the queue > and don't kill the queue). I think we need a method to differentiate > between them. > > And, just to throw something out there... suppose I'm queueing bulk-in URBs > to transfer some data. But, my CPU is slow (for whatever reason -- perahps > I'm decoding too much p0rn DVD), and I don't actually submit the 3rd URB > until after the 2nd completed. But, the 2nd completed with a short > packet.... so what's the behavior? If #2 and #3 were submitted before #2 > completed, then #3 would terminate (under your rules, see above). But, now > we have a race condition where #3 doesn't terminate because it doesn't > appear to be part of a long queue of URBs. > > It's those sorts of sceanrios I'm worried about. Again, I return to my > argument about scatter-gather, which is what I see as the primary use of > queued URBs. > > Matt > > -- > Matthew Dharm Home: [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > M: No, Windows doesn't have any nag screens. > C: Then what are those blue and white screens I get every day? > -- Mike and Cobb > User Friendly, 1/4/1999 > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel