On Sun, 23 Feb 2003, David Brownell wrote: > >>A better way to say it may be: if that's not what disconnect() > >>means, than what the heck _does_ it mean? There are a whole LOT > >>of answers in current use. Clearly the idea is to prohibit some > >>kinds of behavior. Which ones? And why _not_ all of them? > > > > It means that the device is physically gone, that's it. What the driver > > wants to do with this information is up to it. But the core has to > > handle attempts to use this device after it is gone, like it now does. > > That's an interesting model, but it doesn't seem to handle some > current usage correctly. Notably rmmod (yes, in flux, and many > layers of things could yet be changed then re-stabilized) and > other cases where the driver would be disconnected while the > device is still present. Drivers would still need to release > locks when the hardware is gone; maybe they can just deduce that > it's time to do that by looking for particular status codes. > > Interesting because of the questions it suggests: since that view > makes disconnect() into nothing more than a hint, why not just remove > that disconnect method entirely? What _other_ things would need to > change if usbcore stopped even providing that hint?
While the subject is in the air, how about device resets? They can be initiated by a driver bound to any interface, but they affect the whole device. I don't know enough about how the core handles resets... the device needs to be re-configured (USB address assigned, etc.), but that doesn't necessarily imply the creation of a new device structure. In fact, it would make sense to keep the old structure, avoid re-enumeration, and re-assign the same address as before the reset. Is that how it works now? But there has to be a way to inform drivers about it. The current approach is extremely ad-hoc: the driver that requested the reset is responsible for calling disconnect() followed by probe() for all the interfaces on the device. That's got two problems: it decentralizes something that ought to reside in the core, and it's too extreme. Resetting should not cause a hot-unplug event followed by a hot-plug, for example -- since we _know_ that it is the same device before and after. But that's just what would happen in the usb-storage driver, e.g. The approach that seems most logical to me is to define another entry point for USB device drivers. This entry point should be called by the core whenever a device bound to the driver is reset. The driver can then decide what to do: maybe re-initialize the device, maybe do nothing. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
