> > 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.
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().
[..]
> > 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,
Yes.
> 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.
Correct and as far as the low level drivers are concerned all is as it
should be. The change we are discussing must be confined to usbcore.
If we need to touch deeper layers we are doing something stupid.
> 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.
> 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.
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
