On Fri, 2 Jan 2004, Oliver Neukum wrote: > Wasn't the driver model supposed to handle parent-children relations?
Indeed. That's an area where the driver model has not been fully adopted into the USB driver framework. > Very well, but I would still suggest a single semaphore (rw if you will) > for the whole tree, for two reasons. > - it is simple > - in error recovery by disabling ports we should (currently don't - but > that's a bug) go _up_ the tree. A rw semaphore like that would work, provided khubd is careful only to use down_read_trylock(). It can't afford to block on the semaphore, because that might lead to deadlock. That is, if rmmod owns the tree writelock and is trying to disconnect a hub, then it will have to wait for khubd's hub_disconnect() routine to run. But hub_disconnect() needs to acquire hub->khubd_sem, and the khubd thread will hold hub->khubd_sem while it is blocked waiting for read access to the tree semaphore. And in fact there's no need for contention -- if the entire tree is in the process of being disconnected there's no point in khubd trying to add or remove children anyway. So if it detects that the tree semaphore is held for writing, it should abandon any attempt to modify the tree. 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
