Alan Stern wrote:
On Sun, 9 Feb 2003, Duncan Sands wrote:
In that other driver structure, synchronizing on urb completions
after an (async) unlink failure would either (a) have succeeded,
because the "failure" was like the EBUSY case, "warp crystals
would explode if we unlinked any faster", or (b) failed because
of some HCD problem.
Success means all is fine; failure (b) would be khubd hanging.
Annoying (reboot to recover, no more modprobes) but 100% safe.
By the way, is there any advantage to
doing an async unlink rather than a synchronous one in this
situation?
This is _exactly_ the point I have been discussing off-list with David!
Short answer: avoiding most of the issues that have caused
confusion on this thread sure seems like an advantage, in
favor of async unlinks.
Peoples' brains work differently, but mine happens to see
drawbacks to to working with the "synchronous" unlink models.
Like needing (in effect) another completion model in the driver;
multiple code paths achieving the same thing can be good if
they're all executed/tested regularly, but that's never going
to happen in unlink/rmm/disconnect logic.
- Dave
Alan Stern
-------------------------------------------------------
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
