On Sun, 2 May 2004, David Brownell wrote:
Physical. This would be only for struct usb_device, not for struct usb_interface, because only usb_device has a children[] array.
But for hub nodes, the two are equivalent. Changing to config 0 will remove child nodes ... I'm afraid that distinction only makes sense for non-hub nodes, where configs 0, 1, 5, and 42 will all have different "logical" children.
Clearly it will have to be up to the hub driver to disconnect all the children when it is unbound from a hub. It should be doing that now, but it doesn't.
It's not been a big issue, and might not become one, but it's an issue worth noting while updating the hub driver.
Apart from that, I don't see what you're getting at. The point seems
You just said you wanted a "topology lock", but there are multiple topologies. A lock that protects the logical topology of a given non-hub device (SET_CONFIGURATION) doesn't need to protect any other device. And a lock that protects the physical topology of a given sub tree (including logical topology of the hub rooting it, both by SET_CONFIGURATION and hub interface bind/unbind) doesn't need to relate to physical topology of any other tree.
simple enough to me: usbdev->children[] is data that will change occasionally but will more often be read. Since usbdev->serialize shouldn't be used to prevent changes during reading, some other lock is needed to protect it.
That "since" is an assumption I still haven't been persuaded of ... what would that lock be used for, then?
Are you suggesting an rwsem or rwlock?
It might not be necessary to do this if we used the driver model links exclusively and did away with ->children[], but since it's there it needs to be protected. And it's becoming clear that ->serialize is the wrong way to do so.
I'm still not persuaded of that.
You have to admit at least that locking hub->serialize is a very strong
action. For example, when populating /proc/bus/usb/devices we don't want to stop hubs from carrying out _all_ of their normal activities; we just want to stop the topology changes. (I suppose you'll say that topology changes constitute the lion's share of what a hub does.)
One of many reasons why having hub->serialize have exclusive/shared modes would likely be a godo thing.
Keep in mind that without correct locking, printing /proc/bus/usb/devices will be a bit error prone ... :)
My main difficulty is with port resets. I just can't see any way to make them work in an environment with top-down locking. If you can come up with a way to do that, I'll reconsider my position.
I really don't see the problem. It's like resume: both involve special signaling sent from one port down the entire tree, so they are both top-down problems from the host software perspective. (Even remote wakeup, where a device signals resume and pushes it up to some hub, which then resumes an entire subtree top-down.)
Thing is, if there's code that locks top-down, and code that locks bottom up, they WILL almost certainly end up deadlocking each other.
Definitely; no "almost" about it.
Which is why anything other than top-down locking bothers me, since we know that we've got a lot of top-down scenarios like disconnect and resume to handle.
Disconnect isn't so bad. We know that we can prevent a hub from adding new children, and then we can disconnect all of its existing children without locking the hub. When it comes time to disconnect the hub itself and it _has_ to be locked, there are no children left to generate a bottom-up locking conflict.
We could also lock it safely, and save everyone the process of arguing about how unlocked tree manipulations could ever really be correct ... :)
Resume also doesn't seem like a problem. We lock a hub to resume it. Then we unlock the hub and resume its children. Top-down locking isn't needed.
It's needed, else khubd and whoever resumes through sysfs will be fighting with each other over who manages the resume.
In fact, the only problem I _have_ been able to identify is: "What happens when khubd is multi-threaded and different threads try to disconnect overlapping subtrees simultaneously?" (Obviously it's not an issue at the
Erm, if subtrees are overlapping, then one of them is a strict superset of the other and you really only have one subtree being disconnected.
moment.) In a bottom-up locking environment your subtree-locking algorithm couldn't be used to resolve this.
Just stick to a straight top-down approach, and the resolution of such problems will dovetail neatly.
- Dave
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
