On Fri, 7 May 2004, Alan Stern wrote: > On Fri, 7 May 2004, David Brownell wrote: > > > > Where "port waiters" being a new notion, like the notion > > of splitting apart the "port" (downstream end of the link?) > > and the device (upstream end?) as separate entities. > > > > Why separate entities for both ends of the hub<-->dev link? > > They _are_ separate entities. When the device is disconnected the port > will remain in existence. It can still generate connect-status-change > reports and khubd still has to manage it.
Now I see what you're getting at. When there's no device attached to the port there's no contention, hence no need for any lock. So to lock the port it will suffice to lock the device attached to it, if any. That will simplify things. It also removes the distinction between cases (A) and (B), thereby removing the need for the extra field in struct usb_device. As another simplification, that usb_driver_reg_locked variable I mentioned before isn't really needed either. The only time it would be used is during a hypothetical rmmod of the hub driver. Since that's not possible we don't need the flag. > I think we really should lock the device during configuration changes. A > certain amount of mutual exclusion with tasks that want to traverse all > the interfaces in the device (like /proc/bus/usb/devices) is required. > The bus rwsem might be sufficient for this, but it locks too much -- all > the USB trees. In principle this mutual exclusion could be accomplished > using something other than ->serialize, but why make things more > complicated than they have to be? I don't think we lose much by doing > regular device locking here. Here's another argument you may find more convincing. I went back and looked at the stuff you wrote before about using a separate lock for the "logical" children. Let's take that one step further and consider using 3 locks: a logical-children lock (LL) that prevents configuration and binding changes, a physical-children lock (PL) that prevents adding or removing child devices, and (for want of a better name) a state lock (SL) that prevents suspend/resume/reset/disconnect. Of course the PL only affects hubs. Notice, however, that any change in configuration or bindings will necessarily cause a change in the physical children, since the hub driver will disconnect all the children when it unbinds. Hence it makes no sense ever to lock PL and not LL. What about the other way around? Locking LL but not PL means you want to keep the interfaces and bindings the same but you don't care if children are added or removed. I suppose you _might_ want to do this on occasion... but there would be no great loss in always locking PL whenever you lock LL. Thus there's no need to distinguish PL and LL at all; they can be combined into a single child-lock (CL). Now notice that pretty much any time you hold SL you also will want to hold CL. That includes times such as during suspend, resume, reset, and config change, because these state changes will affect all the interfaces. There are a few times when you might want to hold CL but not SL, such as during tree traversal. But these will be sufficiently infrequent that I think there's no harm in combining CL and SL into a single big lock -- and that's what serialize is! > I haven't gone through all the details of this. It's not clear that all > those states are needed, for example, although they do form a logical set. > My main reason for adding them was to let usb_reset_device() work in as > many contexts as possible. One thing I am certain of is that the > interface field needed to deal with the usb-storage/SCSI-EH problem. If > that problem goes away then the field can probably go too. It turns out that's not correct; the field is still needed so that reset-during-probe can be detected. When a reset is done as part of the probe sequence there's no need to lock the device, so we have to be able to tell when that is happening. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
