On Mon, 3 May 2004, David Brownell wrote: > 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.
I'm talking about protecting the physical topology of the entire tree. That's what /proc/bus/usb/devices needs if it doesn't want to get lost in a maze of twisty little pointers, constantly changing. Yes, strictly speaking, when it's not looking at a particular subtree then it doesn't need to protect the links in that subtree. And I would find it acceptable to use hubdev->serialize to protect the links at the inner nodes if only I could see how to also get usb_reset_device() working reliably. And useable from within probe(). > > 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? ->serialize is used for plenty of other things, like preventing two processes from changing a device's configuration simultaneously. > Are you suggesting an rwsem or rwlock? Definitely a semaphore, not a lock. It could be an rwsem but it doesn't need to be; reads and writes both occur pretty infrequently. > > 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. Well, yes. Although after more thought, I guess it doesn't hurt to stop a hub from doing stuff for a short while. > Keep in mind that without correct locking, printing /proc/bus/usb/devices > will be a bit error prone ... :) That's exactly what I'm concerned about. > > 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. Yes, but you still might have two processes working on overlapping subtrees at the same time. For instance, khubd gets a port-connect-change on some port, and while it's working on that you rmmod the HCD. With top-down locking this probably isn't too bad a problem. 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
