Am Donnerstag, 29. April 2004 23:04 schrieb Alan Stern:
> 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.
No, think about it. The problem exists only because we don't wait
for the completion handler. It doesn't look the same, but it is.
> 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!).
No, as you yourself have pointed out, the problem is not confined to
disconnect(). Reusing the URB has the same problem. If we stay with
the example, the bug is not only in disconnect() but also in close().
We cannot solve it with disabling, because we may need to reenable
in arbitrarily short periods of time.
> > > 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.
I would _like_ to call it usb_kill_urb()
But we are in a stable series. IMHO using the same function for synchronous
and asynchronous unlink was an error in the first place.
> > > 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.
Not that hard.
Regards
Oliver
-------------------------------------------------------
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
