On Thu, 29 Apr 2004, Oliver Neukum wrote: > > 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. > > True, iff the unlinking returns no error. But the problem is the window > while you cannot unlink. It seems to me that many network drivers are > buggy in that respect with respect to soft disconnect().
Probably not just network drivers. But this is really a separate issue. It would better be solved by having a way to prevent the resubmission from succeeding in the first place. Maybe some way to ask usbcore to fail all URBs for a particular endpoint (although the URB might be resubmitted for a differend endpoint!). > > 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. > > In principle I agree. I don't really care whether you remove synchronous > unlink or make it a useful wait_for_urb(). However I feel that changing > the semantics of synchronous unlinking can be done in a compatible way. > Therefore in practice I consider that solution better. I think David might agree, provided you call it something other than "unlink". Once the semantics are changed, it's no longer just an unlink operation. > > 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. > > Would, but aren't ;-) > IMHO this is the same race condition. If you wait for the completion handler, > you've beaten the resubmission problem. Ah, but that's very hard to do correctly. 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
