Hi Dave, I think this one
* Removes driver->serialize ... not needed, since it's only gotten when the bus writelock is held.
is problematic for efficiency reasons: suppose I want to protect myself from (for example) configuration changes. By taking dev->serialize I am taking a per-device lock, so
I think you mis-read something: dev->serialize is a different lock from driver->serialize. Only one of them is superfluous -- though the names are similar.
Other than that, did you think this would cause any problems with the usbfs changes you're looking at?
For that matter, if dev->serialize was a rwsem, then contention could be reduced even further.
I saw you did explain that suggestion in a different email, and I've not responded to it yet. It seemed plausible on first look, but I wanted to take a closer look at what you said and compare to the code.
Something to keep in mind its that there's essentially a two level locking hierarchy going on. The top level is the device, dev->serialize, which controls whether its config can change. Below that are the interfaces, which get involved with the bus rwsem.
I don't think I noticed you saying anything in conflict with that, but I did want to point out (for the peanut gallery if nobody else!) that root cause for some of the complications with config changes.
- Dave
------------------------------------------------------- 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
