On Thu, 29 Apr 2004, Oliver Neukum wrote: > > > 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.) > > But doesn't the large majority of drivers unlink only synchronously?
As far as I know, no one has completed a survey. :-) > It seems to me that the desired semantics for synchronous unlink > if the completion handler resubmits is to unlink the newly submitted urb. Now you're getting into a race between unlink and resubmit. On the whole, the problems are so difficult that it's probably best to punt and agree that anyone whose completion handler resubmits a synchronously-unlinked URB deserves whatever they get. > > > > 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; > > But in any such case giveback_urb() has been or will be called, right? Yes. > Am Donnerstag, 29. April 2004 20:07 schrieb David Brownell: > > Oliver Neukum wrote: > > > > > > But we don't violate existing behavior, do we? > > > Always returning only after the completion handler has run seems > > > to be legal to me. > > > > And it does return after the completion handler runs -- iff the > > unlink succeeded, and it was a synchronous unlink. > > > > > > Making it wait even if the URB was completing normally would indeed > > change the semantics ... remember the routine is all about UNLINKING. > > Which is why using it to achieve anything else is bogus. > > Why, if nobody wants to just unlink synchronously? > > Is there a requirement that usb_unlink_urb() block only if there's no error? > Or, in other words, is software that is broken if it always waits? You see, now you're getting into a question of semantics. To David, unlinking an URB means taking it off usbcore's internal lists and telling the HCD to get rid of it as soon as possible. (The very word "unlink" is suggestive of removing the URB from an internal linked list.) It does _not_ mean sending the URB to the completion handler -- that happens sometime after the unlink, when the HCD is ready to give back the URB. Your point, which I agree with, is that drivers don't really want synchronous unlinking (by this definition). They want to unlink and wait until the completion handler has run. That's why usb_wait_for_urb() was written -- it does what drivers want when used in combination with either synchronous or asynchronous usb_unlink_urb(). Synchronous unlink is kind of an orphan child. It doesn't do exactly what the callers want and it is implemented via an ugly hack. (Several subroutines in hcd.c would be simplified if we didn't have to handle synchronous unlinks.) That's why I want to do away with it. The big conceptual difficulty is handling resubmission by completion handlers. If it weren't for that, synchronous unlink could be replaced by asynchronous unlink plus usb_wait_for_urb() right now. We would all be better off. 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
