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. Apart from that, I don't see what you're getting at. The point seems 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. > > 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.) 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. > > The business of going up the tree is a little odd, yes, but it's limited > > to a couple of cases where we go from a device only to its parent hub. We > > never go all the way up to the root (unless of course the parent happens > > to be the root hub). > > 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. 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. 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 moment.) In a bottom-up locking environment your subtree-locking algorithm couldn't be used to resolve this. 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
