Hi Alan, On Friday 07 February 2003 16:20, Alan Stern wrote: > 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?
That was a guess - and it seems wrong (I should have taken the 30 seconds needed to check...). I can't in fact see anything that stops the module being unloaded after a successful probe! I assumed that the driver would be registered with sysfs and sysfs would take a reference, but if so I can't find it. > > - 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. For example, the device is unplugged. > > 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. That's good to know - since most drivers assume it cannot fail! > > 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. I thought MOD_INC_USE_COUNT had gone away in 2.5, but perhaps it still exists under another name. Still, shouldn't the USB subsystem be doing this for you in 2.5? > > - (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! Sure. In 2.4 it is clear that you should be using MOD_INC_USE_COUNT. But in 2.5 that way of doing things seems to be deprecated. > > 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. Ciao, Duncan. ------------------------------------------------------- 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
