On Fri, 23 Jan 2004, Greg KH wrote: > > 3. Mark usb_devices as soon as we know they are unplugged? David > > is strongly in favor of this and I don't see any real problems with it > > either. It does raise the problem of protecting usbdev->state because > > it means state can change to NOTATTACHED at any time, even while > > usbdev->serialize is held by another task. > > Ok, I like this idea, but we need to be careful about it. I got it > wrong last time I did it, so I'm hesitant :)
I'll be careful. At the moment I don't foresee any problems. > > 4. How to protect the global bus topology? So far this issue has > > been ignored, leading to incorrect code as I'll discuss below. For now > > just note that whatever mechanism protects the topology would also > > naturally protect ->state, since state = NOTATTACHED indicates a topology > > change. > > The rwsem for the usb bus should protect this, right? That may work -- I need to check when and for how long the driver-model core holds the rwsem. Certainly it would be appropriate. The main thing to watch out for is the order of locking; it always has to be usbdev->serialize first, then usb_bus.rwsem. That will make things a little awkward for usb_disconnect() when recursively removing the children of a disconnected hub, but it won't be too bad. > Heh, what about the code in the devices usbfs file? That's so scary > that it even works at all... > > Sure, fixups in this area would be appreciated, for 2.7. > We can't rely on doing something because we think the device is > attached. All we can know for sure is that something is not attached. > In other words code that tries to do: > if (usb_dev->state == ATTACHED) > do_foo(); > > is wrong and racy. > > But code that does: > if (usb_dev->state == NOTATTACHED) > goto reject_urb; > > It's touchy code, just be aware of it. I am. As far as I know, there isn't (and won't be) any code that assumes, merely because usbdev->state != NOTATTACHED that the device actually is plugged in. No conversely does any code assume that if the state is NOTATTACHED that the device hasn't just been replugged (although I can't see that assumption making any difference). > > Likewise, if the device hasn't been unplugged then reinstall > > altsetting 0 after calling the driver's disconnect(). > > This might mess some devices up, but is worth trying for 2.7 I get the impression you feel that most of this doesn't belong in the 2.6 series, at least not at first. When will 2.7 start up, or at least, when will you start accepting patches to make some of these changes? 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
