On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called "programming by contract".
And the contract is: usbcore agrees to work with your driver and do everything right, if your driver agrees to do a few specific things. One of those specific things is never using the device after you return from disconnect(), either directly (as you're doing here) or indirectly (urb still pending, say).
Pity this contract is undocumented.
And flat wrong.
That's pretty extreme -- are you like totally pooh-poohing on all the "programming by contract" disciplines? If so: why? and how else would you specify interfaces? Or if not: then what particular aspect(s) of that contract seem wrong to you?
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?
As Alan said, that contract needs to finally get written down. There's too much mis-understanding, and even in 2.5 we've not yet gotten rid of all the HCD-specific behaviors (or bugs).
I'm comfortable saying that for 2.4, if your driver still hasn't implemented that policy, it's got needless instability. That has improved in 2.5 kernels ... a lot more drivers live within that policy, AND I think there are some more forgiving code paths.
- 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
