Greg and Pat: I've heard there's work going on to allow for manual binding and unbinding of drivers to devices, although I haven't seen any of the email. (URLs appreciated!) Here's a subtle point which may not have occurred to anyone yet: When a device has children, what should happen to them when its driver is unbound? Without a driver to manage the device, there would be no way to know when the children should be removed.
There probably are situations where this doesn't matter. But in general, don't you think the driver core should automatically remove all children below a device that has just lost its driver? Or is it good enough to rely on all the individual drivers to make sure the problem can never arise? With USB the situation is even more complicated. When a USB device has USB children (i.e., it's a hub), the relevant driver isn't even bound to the parent device! That is, the hub driver doesn't bind to the hub device; instead it binds to an interface. Logically a hub's children should really be children of the interface, but they aren't and it's too late to change now. This means we should take care either to prevent the hub driver ever from being unbound from a hub with children or else to make the driver unregister all the hub's children when it is unbound. I'm not sure which is the better alternative. We do have code to prevent people from unbinding the hub driver via usbfs if the hub has children. But there's nothing to prevent them doing it through sysfs (set the hub's bConfiguration to 0) or via this new mechanism. It's even worse for root hubs. Not too long ago I added two routines that assume root hubs are _always_ bound to the hub driver, even if there are no children. (In case you're interested, the two routines are used for unregistering everything below the root hub when a host controller dies and for resuming a root hub when a wakeup request is received. Both of these jobs require a process context, and khubd seemed like an ideal process to use.) Of course these routines can be changed to work with whatever policy we choose. What should be done? Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
