On Tuesday 14 January 2003 22:13, David Brownell wrote: > That is, you want to solve the general "callback into module > being unloaded" problem.
I think he want to solve the general "usb_unlink_urb() does its job" problem. The driver may free internal data structures after killing the urb. > As Alan pointed out, the resubmit logic needs to be informed that > resubmission is no longer desired ... just like a timer resubmit. > > So this issue is already in the hands of that device driver. It's > easy enough to solve (flag tested under spinlock in completion), > and already a requirement for drivers ... so the usb core/hcd logic > doesn't need to add overhead for that reason. I agree. This one is easy for the device driver writer. The completion routine is part of the device driver, and the device driver should decide what to do. > >>Likewise, "hcd.c" certainly guarantees that for _successful synchronous_ > >>unlinks, the completion handler returned. 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()? > - It clearly mustn't be a guarantee for asynchronous unlinks. I agree. > - Just as clearly, there are fault cases where unlinks can't > possibly succeed (urb isn't linked, etc). Unlinking a not-linked urb is some sort of success! You get what you want. > Defining a new synchronous call, something like > > int usb_perform_urb (struct urb *urb, long timeout); Bad name: it means nothing to me. best regards Wolfgang Mües ------------------------------------------------------- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
