On Wed, 22 Sep 2004, David Brownell wrote: > Yeech. Even if it were necessary -- which it is not! -- I say: Yeech. > Public locks are error prone, even in controlled environments; and > I seem to have noticed that Linux isn't particularly controlled!
I think any locking scheme is going to end up requiring some assistance from drivers. If you try to do absolutely everything from within the core you just end up with the same re-entrancy problems. > That's only part of what "worsens"! :) > > I see what you mean about preventing deadlock, but then if every > driver is going to be lock-aware why not make the scopes _small_ > so that those structural problems are minimized? Is this a rhetorical question? That's more or less what I've been saying! > > The existing PM data structures aren't quite up to the job. But if the > > children of each parent were linked in a "siblings" list (which struct > > device does include but struct dev_pm_info doesn't) it would be possible. > > Yes. If pm_info had a list entry, normally empty, then it could > be used to flatten any subtree prior to something (USBcore, PMcore, etc) > walking the list and then removing the entries. dev_pm_info does have such an entry. > I was thinking of something different, something like > this for a prefix walk (as for resume): > > walk_subtree(DEV, visitor) > list_head MYLIST = ..initialize me..; > > grab flatten lock; > if dev->pm.list not empty > fail; > add DEV to MYLIST using pm.list > list_for_each ENTRY in MYLIST safely > list_for_each CHILD in ENTRY->children > if CHILD->pm.list not empty > fail > append CHILD to mylist using pm.list > drop flatten lock > > // front-to-back walk for resume > // back-to-front walk for suspend > list_for_each ENTRY in MYLIST safely > visit(ENTRY) > delete from ENTRY->pm.list > > VOILA! > > Clearly those "fail" cases need attention; they could maybe > just wait_event. Little glitches: hey, did you notice > that the "PM Tree" is really a forest? Multiple roots. Yes. So is the device tree. > One difference between that scheme and the one you sketched > is that the "fail" cases exist ... so that when two tasks > are concurrently working on subtrees, they get sequenced > properly. Yes, locktree() does that too... :) Thanks to your "flatten lock", different tasks can't construct lists for disjoint subtrees simultaneously. That probably doesn't matter, because constructing the list goes fairly quickly (unless one of the "fail" cases occurs, but you could drop the lock while waiting). Your scheme doesn't have a way to visit the parent both before and after the children, say, to lock the parent first and then unlock it afterward. I suppose you could accomplish almost the same thing by going through the list a second time, backward, to do the unlocking. What happens if, after you've dropped the flatten lock and before you've visited it, one of the devices on your list is unregistered? The bare-bones algorithm in my earlier email didn't contain contain any locking -- if you want things to work _correctly_ in a multitasking environment you have to pay extra! :-) Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
