Oliver, I like your messages. You always make me stop and think again. :-)
When starting this thread, I had in mind some fairly small changes that would easily go into the 2.6 kernel series. But the kind of thing you and David are suggesting would be much larger, affecting most of the USB drivers. It should wait for 2.7. On Tue, 6 Jan 2004, Oliver Neukum wrote: > Am Dienstag, 6. Januar 2004 00:06 schrieb Alan Stern: > > A hub doesn't have any state that it needs to preserve across a reset, or > > at least none that can't be reconstructed after the reset. Since the > > reset will automatically disconnect all downstream devices, we not only > > don't want to save the current state, we want to get rid of the state as > > easily as possible! > > Not true for the downstream devices. I meant that in 2.6 we should get rid of the state. You are saying that once we institute this big change, in 2.7, the hub driver will want to maintain the port states during a reset so that downstream devices can be reconnected with their drivers properly. I agree. > > A more sophisticated approach to this whole thing would be to make drivers > > aware that their device might undergo a reset for external reasons at any > > time. If the driver had some way to be notified of an upcoming reset then > > it could take steps to restore the device to its original state > > afterwards. Thus all drivers for devices downstream from a malfunctioning > > hub could be notified before (and again after) the hub is reset. > > Similarly, drivers bound to multiple interfaces could be notified when one > > of them decides to reset the device. (But what is a driver supposed to do > > about incoming requests during the reset period when the device is > > unavailable? Fail them, delay them, or whatever?) > > > > I suspect this is all too esoteric for us to worry about, at least for > > now. > > On the contrary. I think you have solved the reentrancy due to reset problem. > It requires two new hooks, though. 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. 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... > [..] > > No, you almost certainly would. The hub upstream of the disconnected > > subtree would report the event within 32 ms (or whatever the status > > interrupt URB period is) whereas the missing hubs would cause single > > errors instead, and the hub driver doesn't do anything until it > > accumulates something like 10 errors. So disconnect processing would > > start at the top of the tree, not in the middle. > > Don't depend on this. It is too brittle an assumption. I'm not depending on it. The code in usb_disconnect() will work okay even if the timing doesn't go the way I said. > [..] > > > > This would permit an attractive concurrency in handling unplug events. > > Concurrency is not attractive, unless performance is an issue. > It is just a source of problems. If something goes wrong in kernel space > you are heading for reboot. It is just a matter of time. 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. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
