On Thu, 29 Apr 2004, Oliver Neukum wrote:
> > Can you come up with something better in terms of both space and time?
>
> I am still thinking, but I am shaping thoughts. Now for some questions:
>
> 1. Does waiting for the completion handler actually change the semantics?
> I would think not, but I am not sure.
You mean, does it change the existing semantics of synchronous
usb_unlink_urb()? Yes, it does. Currently usb_unlink_urb() guarantees
that when it returns the completion handler will have finished _only_ if
it returns with no error. If it returns with an error code then the
completion handler might not even have started running yet.
> 2. Is there objection to introducing a 'phase' field to struct urb?
I personally don't object, but other people do. However, I doubt that
adding such a field will be sufficient to do what you want. There are
pretty thorny problems associated with the possibility that the completion
handler is allowed to resubmit the URB. My version of usb_wait_for_urb()
ignores those problems: If the URB is resubmitted by the completion
handler my routine will hang. For a general-purpose synchronous unlink
that might not be acceptable. (On the other hand, it might -- synchronous
unlinks _ought_ to be uncommon and it doesn't make sense to automatically
resubmit following a synchronous unlink.)
> 3. Under which circumstances can retval = hcd->driver->urb_dequeue (hcd, urb);
> fail?
That's slightly different from asking when usb_unlink_urb() can fail.
hcd->driver->urb_dequeue() can fail if:
The URB is no longer queued, i.e., it has already completed
or otherwise been dequeued;
The URB was not fully queued in the first place, i.e., on an SMP
system you manage to call hcd->driver->urb_dequeue() before
another processor had finished executing the previous call to
hcd->driver->urb_queue(). In such circumstances the call to
urb_queue() will end up failing as well; however this still
counts as a successful unlink, although not a successful dequeue.
For your information, usb_unlink_urb() will fail whenever urb->status !=
-EINPROGRESS. In general, that can happen if:
The URB has already completed, even if the completion handler
isn't finished yet;
The URB was unlinked (either synchronously or asynchronously)
already, even if the completion handler isn't finished yet;
Other similar causes, such as urb->timeout expired (supported
only by UHCI and likely to be removed in the future) or device
unplugged and so all outstanding URBs cancelled with -ESHUTDOWN.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
