As far as I can tell an URB should have four states, with preliminary names:
1 - URB_FREE
Try "IDLE" or something; if it's freed, it's owned by the
memory management code, and usb would never see it.
2 - URB_SUBMITTED
3 - URB_COMPLETING
4 - URB_CANCELED
If there's a CANCELED state it should just be a sub-state
of SUBMITTED ... one where urb->status isn't -EINPROGRESS,
but is -ECONNRESET (async unlink), -ENOENT (synchronous
unlink) or -ESHUTDOWN (cleanup after host controller halt
or power loss).
That way the initial state is always IDLE, it always goes
from there to SUBMITTED, and then becomes eligible to go
through COMPLETING back to IDLE by (a) hardware-initiated
completion, normal or fault; else (b) software-initiated
completion, by unlinking.
Then we can define invariants:
- when submitting urbs, they may be either IDLE
(for first submit) or COMPLETING (resubmit from
completion).
- when unlinking urbs, they must be in SUBMITTED
- when (really) freeing urbs, they must be in IDLE
- usb_alloc_urb() returns IDLE urbs, and those are
the only kind the various init_urb calls take.
Only usbcore would be allowed to change urb->state,
and everyone spinlocks urb->state before accessing it.
Do we have to guarantee that usb_submit_urb() returns before
the completion handler is called?
Why should any caller ever care? It's an async API
- Dave
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
