Hello David, On Wednesday 15 January 2003 00:12, David Brownell wrote:
> > Good. Now eliminate the unsuccessfull synchronous unlinks. Nobody wants > > them. What should a device driver do if there is an error in > > usb_unlink_urb()? > > Getting back to one of my first responses on this thread. What > Oliver has proposed doesn't start to address those issues at all. Hmmm. Your answer is like a no-op to me. A function which is used for cleanup usually *don't* has a return code. This is good programming practice. usb_unlink_urb() violates this rule. > > Unlinking a not-linked urb is some sort of success! You get what you > > want. > > Well, "some form" which by all rights should be reported using some > kind of fault code. No, Sir. > Passing in parameters that don't meet preconditions > of the call is an error on the part of the caller, and masking errors > tends to cause trouble. You may emit a warning in debug mode... How about: one thread is calling usb_unlink_urb(synchronous), meanwhile the completion handler gets called, and usb_unlink_urb continues and tries to unlink the - already unlinked - urb. This is a common problem. Should the device driver get an error about that? Why? If it is common to get meaningless errors from functions, device driver writers will come to ignore errors ... maybe all errors. IMHO it is good design that cleanup functions don't have an return errorcode. best regards Wolfgang Mües ------------------------------------------------------- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
