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?
We've had separate discussions about the "real physical disconnect". We can (and IMO should) force that to shut down urbs-in-flight; if disconnect() isn't used, or misbehaves,
But that doesn't help the logical disconnect (device still present, it's the driver that's going away, not the device) cases work. In that case I think the "it's just a hint" semantics won't behave well.
- Dave
------------------------------------------------------- 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
