On Tue, 5 Dec 2006, Greg KH wrote: > On Tue, Dec 05, 2006 at 10:20:49AM -0500, Alan Stern wrote: > > I am undecided. Here are the issues: > > > > 1. Will people have lots of devices hooked directly into a > > root hub? If yes, then something like the patch I sent > > before would be good (handle multiple ports on a single > > hub in parallel). > > > > 2. Will people have lots of external hubs? If yes, then it > > would be better to start up several khubd threads (handle > > multiple hubs in parallel). > > I think this has the best chance for speedups on large systems with lots > of hubs. > > > 3. Would a combination of 1 & 2 be better than either alone? > > Possibly. > > > 4. Is the payoff too small? Maybe it would be best to do > > nothing at all. > > No, I'd like to have something as it's just too annoying when one device > or driver hangs and takes the whole rest of the usb scanning down with > it. Any way to make this more robust is a good idea.
One thing we can't get around is that probing and unbinding a driver both require you to hold the device's semaphore. If a driver crashes during a probe, it doesn't just take down its own thread -- it will also hang any thread trying to unregister the device (say if the device is unplugged because it isn't working). And it will hang any thread which scans through all the USB devices, acquiring each one's semaphore in turn (like lsusb). Not only that -- in order to prevent races between registering and unregistering new child devices below a hub, we require such activities to be done while holding the hub's semaphore. So a crash while probing a new child device will leave the hub locked. Each USB event on that hub will then cause another of khubd's threads to hang. So by adding more khubd threads we could keep the USB subsystem running for a little while, but pretty soon they would all be blocked. Let's face it, a buggy driver will take down the whole subsystem sooner or later (probably sooner). Given this, I think we should try to insure robustness by making each of the drivers safe, not by trying to work around their failings. Which means that the only reason for doing parallel probing would be for a performance gain, as opposed to a reliability gain. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
