Okay... so I'm almost convinced... just one more detail. For queuing bulk URBs like this, which completion handler(s) is/are called? All? Just the last? Some other pattern?
I can probably rig up some tests for this... it's a bit tricky, but not impossible. Are all the HCD people willing to commit to making this go, however? Matt On Wed, Nov 28, 2001 at 07:14:02PM -0800, David Brownell wrote: > > I'd love it to be atomic, but is that really practical/possible? > > Certainly. I'm told some USB stacks do it by setting a driver halt > state on error, so that submitting subsequent requests will fail > automagically. That's really the only problem case; if there's no > error, there's no way a problem would show up.. > > > > 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, > > Simpler yet: if the "do bulk queue" flag is set in the URB, and > it gets an error, halt the endpoint. Queuing the next URB > would fail, and by defninition any already-submitted URBs > would be getting canceled automatically. That "halt" might > need to be magic, so clearing it doesn't normally talk to the > device ... there's some old code in usbcore that looks like > that was the original idea, but which has since morphed. > > > > ... (again), this is a place where consistancy across HCDs is lacking. > > And testing will be an issue, too. I should be able to make sure > that the EHCI driver handles queued bulk requests reasonably, > since I've got a device I can program easily enough, but doing so > for other HCDs will need more effort. > > Has anyone done anything with "usbstress" lately? > > - Dave > > > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I'm a pink gumdrop! How can anything be worse?!! -- Erwin User Friendly, 10/4/1998
msg02756/pgp00000.pgp
Description: PGP signature
