On Tue, 28 Jan 2003, David Brownell wrote: > Alan Stern wrote: > > > > Calls to usb_unlink_urb() while the completion handler is running > > won't do anything until the handler has returned. > > It still violates the API spec: there's no completion callback with > an unlink status (-ECONNRESET, -ENOENT). It shouldn't masquerade as > a call that behaved correctly (unlink status callback guaranteed).
I don't think I understand your objection. Are you saying that if a driver calls usb_unlink_urb() while the urb's completion handler is running, then back when the handler was originally called the value of urb->status wasn't -ECONNRESET or -ENOENT? That's clearly unavoidable and hardly a violation of the API spec; after all, the instance of the urb for which the handler is running _wasn't_ cancelled (at least, not by this call to usb_unlink_urb()). Or are you saying that if a driver calls usb_unlink_urb() while the urb's completion handler is running, then after the handler returns it won't get called again with urb->status set to -ECONNRESET or -ENOENT? If the handler doesn't resubmit the urb then that is true, but it still isn't a violation of the API spec. Instead, usb_unlink_urb() returns -EBUSY, meaning that the urb has already completed. If the handler does resubmit the urb, then the objection is false: when the handler returns the resubmitted urb will then be unlinked and its completion handler called with the appropriate status. > I've still got a bunch of messages in my inbox, maybe one of them > will persuade me that (2) needs solving. I can't yet see why though; > particularly the "... and its handler has exited" part, since that's > easily guaranteed by calling synchronize_kernel(). Maybe it doesn't really need solving. But as things stand, the API spec probably could use some revision. It says: * When the URB_ASYNC_UNLINK transfer flag for the URB is clear, this * request is synchronous. Success is indicated by returning zero, * at which time the urb will have been unlinked, * and the completion function will see status -ENOENT. I note that this makes no guarantees about when the completion function will run with respect to the return from usb_unlink_urb(); it only says that the status will be -ENOENT and that the urb will have been unlinked. What does a driver care about when the urb is unlinked from whatever data structures the core uses? All the driver wants to know is that the completion handler has run. After all, the driver can't do anything to the urb until then anyway. From the driver's point of view, the only difference between synchronous and asynchronous in the current API lies in their status codes and the fact that one of them can block. IMHO, the API should be changed to indicate that a synchronous call doesn't return until the completion handler has exited. There's no point in not doing this, especially considering that synchronous unlinks are merely a convenience provided for drivers. After all, there are enough synchronization primitives available for a driver to tell on its own when the handler has run -- the whole point is that it shouldn't have to go to the trouble. Alan Stern ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
