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
