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

Reply via email to