Okay, in a separate thread on LKML Andrew Morton has said he doesn't really like my approach either. Then what should it be?
It also conflicts with the locktree() model, since it doesn't actually obey a parent-first locking policy.
So there's no locking "this hub and below"; usb_lock_device() will gladly grant most any unclaimed udev->serialize at all. I'm not keen on trying to handle resumes initiated from within trees that are partially suspended ... best to finish suspend processing before starting other changes in that tree!
Clumsily use different routines for locking the first vs. the
others in a nested set? (Or clumsily force drivers that want
to lock more than one device to explicitly acquire and release
the readlock?)
The way you call everything "clumsy" makes me suspect you really don't like these notions particularly much ... :) But since your other option was a single global lock, these look to be far more congenial directions.
If you're really keen on hiding the rwsem, then there's no way around the notion of different rules to get the first lock and the subsequent ones -- short of reentrant locks, which are REALLY worth avoiding.
But I have no problem with that; it's what locktree does already, after all. What it _needs_ to do in fact.
I started to look at making usb_lock_device() be locktree() underneath. Issues:
- Code now doing lock_device(hdev->child[i]) would change;
the top level would lock_device(), lower levels would
just down(&udev->serialize) and thus, at most, wait for
a previously-started task to complete. I only saw a
couple obvious instances to change. - The "device is gone" fault mode is handled differently.
Much of the code you touched was just failing there,
after getting the lock; locktree() doesn't bother even
grabbing the lock when it'd be meaningless. - That special lock_for_reset() logic needs more thought.
Maybe it just needs a trylock() version of locktree().There were a couple other minor tweaks, but the big issues were the "lock never fails" policy, and lock_for_reset().
- Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
