On Tue, Nov 27, 2001 at 10:40:14AM -0800, David Brownell wrote:
> > (2) What about the race condition between submitting URBs with QUEUE_BULK
> > and having one of them terminate?  That is, what if we're doing a read and
> > the first URB gets terminated with a short-packet _before_ we submit the
> > 2nd URB of the data sequence?
> 
> That's one of those "should not happen" cases that's got the feeling of
> something that will actually show up in some cases ... :)
> 
> >      Will the 2nd URB get retired because the HCD
> > recognizes this based on the QUEUE_BULK flag?  Or does the status end up in
> > the userspace buffer?  
> 
> I think the right model, outside of whatever layer this is, clearly is
> that submitting the set of URBs (and getting back clean status)
> is an atomic action.  There are a lot of ways to achieve that.
> 
> I think it ought to be doable without API changes to usbcore.
> It's sort of like the submit-time analogue of the unlink races
> that crop up when drivers unlink URBs as HCDs are firing
> completion handlers.  It'll need some attention, but it's a fixable
> problem.
> 
> >        Can the driver tell the difference then between this
> > case and a very slow device stuck in it's data-transfer phase?
> 
> I don't follow this question at all -- are you assuming that the
> set of queueable URBs isn't submitted atomically?

That is my assumption.  Since I, as a driver author, can't guarantee
anything with regards to how much CPU I get to submit URBs, I have to
assume that there is an arbitrary long delay between each URB in a
scatter-gather list.

I'd love it to be atomic, but is that really practical/possible?  We'd wind
up delaying the submission of the first URB until we were sure a chain of
them was complete, and that means likely introducing either (a) some sort
of "end of bulk-queue" chain flag, or (b) building lists of URBs and
submitting the head, letting the HCD to the rest (which is very close to
implementing s-g in the core).  Interestingly enough, choice (b) might be
possible if the ->next pointer was used for an automatic-submit mechanism,
but (again), this is a place where consistancy across HCDs is lacking.

Matt

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

What, are you one of those Microsoft-bashing Linux freaks?
                                        -- Customer to Greg
User Friendly, 2/10/1999

Attachment: msg02732/pgp00000.pgp
Description: PGP signature

Reply via email to