Am Montag, 23. April 2012, 17:42:11 schrieb Alan Stern:
> I don't like the idea of changing the status codes. It would mean
> changing usb_kill_urb too.
Why?
> Instead of changing return codes or adding locks, how about
> implementing a small state machine for each URB?
>
> Initially the state is ACTIVE.
>
> When the URB times out, acquire the lock. If the state is not
> equal to ACTIVE, drop the lock and return immediately (the URB
> is being unlinked concurrently). Otherwise set the state to
> UNLINK_STARTED, drop the lock, call usb_unlink_urb, and
> reacquire the lock. If the state hasn't changed, set it back
> to ACTIVE. But if the state has changed to UNLINK_FINISHED,
> set it to ACTIVE and resubmit.
>
> In the completion handler, grab the lock. If the state
> is ACTIVE, resubmit. But if the state is UNLINK_STARTED,
> change it to UNLINK_FINISHED and don't resubmit.
>
> This is a better approach, in that it doesn't make any assumptions
> regarding synchronous vs. asynchronous unlinks. If you want, you could
> have two different ACTIVE substates, one for URBs which haven't yet
> been unlinked and one for URBs which have been. Then you could avoid
> unlinking the same URB twice.
That would work, provided we extend the status machine by an error
code when resubmission is not desired and check for UNLINK_STARTED
also when a timeout begins. But I wouldn't call that a simple solution.
Regards
Oliver
--
- - -
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
16746 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
- - -
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
