Am Mittwoch, 15. Januar 2003 00:12 schrieb David Brownell:
> 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.
"successfully unlinked" is exactly the issue. I want usbcore to
guarantee that you can free after you've called usb_unlink_urb()
Simply calling, nothing more.
> >>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 ...
Not good. If the drivers need to implement additional logic, then the
existing API is insufficient. The point is not that the job can be done
with the API. It's undoubtedly possible. But if that code is needed
in a majority of cases, it should be centralised. More code in usbcore
and less in the drivers is a large advantage and growing larger the
more drivers are added.
> >>>>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.
The driver should not need to care. It should have only to call
usb_unlink_urb() and know that the URB is absolutely eradicated.
The core won't touch it any more, you can free all buffers associated,
no completion handler is running and the completion handler won't
resubmit.
That's what the device drivers really need.
> >> - 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.
Correct. There are two cases of usb_unlink_urb() being called on an
unlinked URB.
Calling it on an URB that is not yet linked is a driver bug.
Calling it on an URB that is no longer linked is not an error,
it's unavoidable. Sometimes it will happen. We need to give
a meaningful response.
> >>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() ?
Don't we have a synchronous API?
Regards
Oliver
-------------------------------------------------------
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
