Wolfgang Mües wrote:
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 indeed is currently possible ... no changes are necessary,
for drivers that have successfully unlinked. None.
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.
Good ...
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()?
Getting back to one of my first responses on this thread. What
Oliver has proposed doesn't start to address those issues at all.
- 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.
Well, "some form" which by all rights should be reported using some
kind of fault code. 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.
Defining a new synchronous call, something like
int usb_perform_urb (struct urb *urb, long timeout);
Bad name: it means nothing to me.
As I said, "something like". What's most important is its
blocking semantics. Maybe usb_wait_urb() ?
- Dave
-------------------------------------------------------
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
