On Mon, 11 Apr 2005, David Brownell wrote:
> Just for the record -- this doesn't look like a change at all, but
> I'm not sure it catches the nuances correctly either.
It is a change, but if that wasn't clear to you then perhaps the wording
needs to be improved.
> On Tuesday 05 April 2005 8:55 am, Alan Stern wrote:
> > @@ -420,12 +420,16 @@
> > *
> > * Host Controller Drivers (HCDs) place all the URBs for a particular
> > * endpoint in a queue. Normally the queue advances as the controller
> > ...
> > + * hardware processes each request. But when an URB terminates with an
> > + * error its queue stops, at least until that URB's completion routine
> > + * returns. It is guaranteed that the queue will not restart until all
> > + * its unlinked URBs have been fully retired, with their completion
> > + * routines run, even if that's not until some time after the original
> > + * completion handler returns. Normally the same behavior and guarantees
> > + * apply when an URB terminates because it was unlinked;
>
> That "normally" bit restates the guarantee provided above.
>
> The redundancy makes things less clear (IMO) because it's
> weakening the guarantee that "when an URB terminates with
> an error" (including an unlink or kill status!!) its queue
> stops ... that says "always", this says "sometimes maybe".
That's just it. The first part applies only when an URB completes with a
hardware error, _not_ an unlink or kill! Do you think this needs to be
made more clear? The second part applies when an URB terminates because
of an unlink or kill. It doesn't weaken the first guarantee because it
refers to different circumstances.
> > + * however if an
> > + * URB is unlinked before the hardware has started to execute it, then
> > + * its queue is not guaranteed to stop until all the preceding URBs have
> > + * completed.
>
> Well, that's because no urb before that one will have
> completed with any fault code, so there was no need
> for the queue to have stopped.
True.
> The relevant urb was
> not yet terminated.
False. The relevant (i.e., the unlinked) URB is terminated by the time
its completion handler gets called. This may well occur before all the
preceding URBs have terminated, since completion handlers are allowed to
run out of sequence when an URB is unlinked.
According to the original wording the queue _would_ be stopped when the
unlinked URB's completion handler was called, even though the hardware
might not have reached the URB yet. The old text said:
But when an URB terminates with any fault (such as an error, or
being unlinked) its queue stops...
So the new text does describe different behavior from the old text.
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
