Hi Alan, We seem to agree.
It seems clear that the best way for the core to handle this situation is: Keep track of all active URBs on a per-device list.
Being done today for HCDs using the new hc_driver framework.
When a device unplugs from the bus, set the device state to GONE and cancel (with some appropriate error code like -ENODEV, which already means the device was removed) all active URBs. Then call the drivers' disconnect() routines. When the device is GONE, fail (with -ENODEV) all calls to usb_submit_urb.
I think Greg implied marking it as GONE was probably doable, but it seems to me like "sysfs" is in a state of flux still so this might need to wait a bit. I'd like to see a hub and all of its children marked as GONE before any of their disconnect() routines kick in, but I suppose both could be done bottom-up. I'd prefer a different error code to indicate "urb unlinked because the device went away", for what it's worth. -ESHUTDOWN is now used in some cases when the HC goes away (remove cardbus adapter, maybe) and I think the same code should be used for both cases (whatever that code may be).
Rely on the driver not to submit any more URBs once disconnect() has returned. If the device structure happens to hang around in memory for a while, you can log an error message (or even oops) on any submissions for a removed device.
This is basically solved by the "clear pointers when they become invalid" rule. It isn't OK for drivers to keep handles to devices (or interfaces) today after disconnect() returns, and that doesn't change in 2.5 either ... you don't seem to be suggesting a change here. But it remains an important rule.
This centralizes the functionality in the core to the largest reasonable extent. The onus on the drivers is minimized; every driver should be able to avoid submitting URBs for devices that they already know are gone.
And better yet: it'll get rid of a lot of disconnect() races/bugs, without requiring every device driver to change! - Dave
Alan Stern
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
