On Sat, Feb 22, 2003 at 06:59:54PM -0800, David Brownell wrote:
> Greg KH wrote:
> >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?

No, I'm saying the contract you wrote above is wrong.  The idea of
"programming by contract" is fine, just write down the correct
"contract" :)

> 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.

> 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).

True, and lots of drivers need to be cleaned up based on this.  I'm
going to be looking through them for the next few weeks I bet...

And yes, writing it down is also a very good idea.  There is a "How to
write a usb driver" document in the kernel, along with a lot of great
comments that get built into the kernel api.  Also, there is an old USB
Programming guide that needs to be updated a lot.  If someone wants to
take all of that and combine it into one document within the kernel, it
would be greatly appreciated.

thanks,

greg k-h


-------------------------------------------------------
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

Reply via email to