Alan Stern wrote:
The whole idea of this exercise is to simplify things for device drivers by giving them an easy way to unload cleanly.
Drivers don't need API changes for that. They just need to guarantee they've implemented disconnect() correctly. Unloading is part of a different kernel subsystem, which 2.5 updated to remove the race that Oliver has historically been concerned with (SMP, with the driver's last completion handler executing its "return" instruction).
There are two issues involved: (1) breaking an indefinite handler-resubmits loop, and (2) knowing when an active urb is done and its handler has exited.
The API change we have discussed really just relates to (1).
This is almost painfully simple, and no more complex than other things we require drivers to do.
The only foolproof way to break a loop like
this is to have the driver set a "stop submitting" flag that the handler
checks. In fact, drivers should be doing something like this anyway. (I
know David Brownell will agree with that :-) Given these objections, it's probably best not to implement (1).
Yes ... :)
(2) can be done separately. It's just a question of grabbing the handler_lock in hcd_unlink_urb() before the call to acquire urb->lock and then releasing handler_lock immediately after.
I've still got a bunch of messages in my inbox, maybe one of them will persuade me that (2) needs solving. I can't yet see why though; particularly the "... and its handler has exited" part, since that's easily guaranteed by calling synchronize_kernel(). - 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
