On Mon, 19 Jan 2004, David Brownell wrote: > Hmm, I seem to recall hearing more approval of the variant that > uses a spinlock to protect the flag during dev->state transitions. > > In fact, the requirements you list below are a great match for > a spinlock: virtually no contention (connect and disconnect are > rare), no heavy work to be done (no kmalloc etc), clearly defined > scope (protects a data structure tree, for one brief shining moment). > > So the disconnect would be "grab the lock, walk the subtree being > disconnected and mark everything disconnected, down_trylock() to > get dev->serialize and if it succeeds, mark it NOTATTACHED". And > then schedule khubd disconnect processing for those devices, to > unbind all the drivers and destroy all the devices.
Maybe it would be best to forget the "unplugged" flag. Instead have the new "topology" spinlock protect the children[] arrays and the ->state values. This means that usbdev->state would be subject to outside change even while someone was holding usbdev->serialize, although the only change that could occur would be to USB_STATE_NOTATTACHED. This version has slightly higher contention for the spinlock, since usb_set_configuration would need to acquire it while changing from the ADDRESS to the CONFIGURED state (or vice versa). But the contention should still be very low: those transitions plus attach and unplug events. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
