I too would appreciate getting some good answers to these questions. My current understanding is limited (and quite likely wrong at some points).
On Fri, 7 Feb 2003, Duncan Sands wrote: > It seems to me that the following is possible: > > - driver (module) registers with USB subsystem > - probe function is called, driver is bound to an interface > - (driver cannot be unloaded now - this is done in sysfs, no?) Just what does sysfs do here? So far as I am aware, it does nothing to prevent the driver from being unloaded. And if it does do something, how does the user tell it when he wants to allow the module to be unloaded? > - driver fires some urbs > - disconnect is called Why would disconnect() be called? The only reasons I know are if the module is being unloaded or the device has been unplugged from the USB bus. > in disconnect driver calls usb_unlink_urb to kill urbs in flight, > but this fails for some urbs. I've been working on the usb_unlink_urb() code. So far as I can tell, it can't really fail unless something is _very_ wrong with the low-level HCD. The standard error codes that it might return don't actually indicate failure; they indicate an attempt to unlink an urb that has already been unlinked, is already finishing up, or has already completed. > Driver decides to follow Dave's > advice and leak memory in this error situation, so it doesn't > free its structures, and exits the disconnect method. > - (driver can be unloaded now). Depending on the usage model the driver follows, this might not be true. For instance, one commonly recommended theme is for the driver to increment its module-use-count each time it submits an urb and decrement the count in the completion routine. When this approach is used, the kernel won't allow the module to be unloaded until there are no active urbs. > - (some urbs are still in flight) > - driver is unloaded > - urb finally completes - completion handler is called - but it doesn't exist any >more > - we are sad If a driver was written to work this way, that would indeed be sad. I guess the best advice is: Don't write your drivers like that! > Or do urbs take a reference to the driver somehow? No. And in any case, the core does not check for any such reference before calling the completion handler. > I'm interested in 2.5 kernels. Me too. 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
