On Wed, 7 Jan 2004, Oliver Neukum wrote: > > The hooks themselves are trivial; it's what the device drivers will do > > with them that's hard! The driver has to know what to do about incoming > > requests while the device is unavailable, it has to be prepared to find > > that the device ends up disconnected instead of reappearing later, and it > > has to be ready to reinitialize the device if/when it does reappear. > > Nothing of this is a new requirement. Treat the new hooks like disconnect > and a subspecies of probe and you arrive at the current behaviour.
You mean, if a driver doesn't want to implement the new hooks, it can treat them the same as disconnect and probe? That's right, and doing so would duplicate the current behavior. In fact, if a driver doesn't set the new hook pointers the core should simply call its disconnect and probe routines instead. > The only > drivers required to implement them would be those using usb_reset_device() > from probe(). Otherwise the driver would receive a disconnect call during its probe. Yes. > Having to wait on IO because a device is not ready is hardly a new > requirement. It is for USB drivers. They usually never do find out that a device is not ready; they just submit an URB and wait for it to complete, however long that takes. This approach won't work during the time that the device is being reset. > > Then there's the assumption that while the reset was in progress, nobody > > monkeyed around with the USB cables, unplugging one device and plugging > > another in its place... > > For the first implementation we can ignore that issue. Long term it can be > dealt with by allowing "reinit()" to fail. For the short term, I agree. For the long term, the problem is not allowing "reinit()" to fail, it's detecting that the device was changed in the first place. I suppose this would be done automatically as part of the hub driver's "reconnect" procedure. That will have to end up looking a lot like the reconnect part of __usb_reset_device() -- not surprisingly, since they are doing essentially the same thing. > > I disagree with part of that. Concurrency is useful for partitioning > > problems, as least for a while. Right now when something goes wrong it > > takes down khubd and thus a very large part of the entire USB subsystem. > > With proper partitioning, a problem would leave some other task hung and > > the device in an intermediate state, but the rest of usbcore would still > > be able to function in a useful way. Sure, a reboot will be needed to > > clean things up, but maybe the system will work better until then. > > It will work unpredictably. If you kill khubd the damage is confined to USB. I don't think it will be so unpredictable. Certainly everything that would work with khubd killed would also work if another task died in its place. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
