> > > >> int usb_revoke_urb_sync(struct urb *urb);
> > > >> int usb_revoke_urb_async(struct urb *urb);
> > > >
> > > >Are you trying to split up the current usb_unlink_urb() case? Do you
> > > >think this is really necessary?
> >
> > I'm not sure why it'd be necessary. The API might be a
> > smidgeon cleaner (I prefer to avoid flags that create API
> > modes, or changing them after requests are under way)
> > but I don't think "necessary" applies here ... those calls
> > would just be wrappers around existing functionality.
>
> It avoids a lot of effort in the disconnect methods of the network drivers
> which would have to check and wait for an ongoing asynchronous
> unlinking.
Now I'm really not following you -- at all.
Are you implying that there's some difference in the synchronous
and asynchronous calls _other_ than the fact that in one case
the unlink is guaranteed to be completed when the call returns,
and in the other it isn't? If so, what's that difference?
If not, I can't understand what you're implying. All disconnect
methods need to guarantee they've completed all pending I/O
requests before they return; not just network drivers. That's
something that drivers using only the synchronous calls (bulk
and control messaging) have a lot easier time getting right;
they can just use binary semaphores.
> > > Much better. The networking drivers have a need to unlink
> > > the same urb both asynchronously and synchronously.
> > > Furthermore it allows functionality to be shifted from the HCDs
> > > to usbcore.
> >
> > That's already done -- the "hcd" framework (part of usbcore that
> > exists only for the HC drivers) handles all the synchronization.
>
> Could you elaborate ?
Maybe if you explain what you find unclear! Look at the code
in hcd_unlink_urb(), and notice that it shifts the wait-for-unlink
functionality into usbcore.o ... and that it also guarantees the
completion always fires before the wait completes. (That should
switch over <linux/completion.h> style, but what's there now works
correctly as-is.)
> > > >> void usb_wait_completion(struct urb *urb);
> >
> > I still haven't seen a description of what this is supposed to do,
> > and would want to see one before a discussion about whether
> > the API should be included ...
>
> if (urb->status != -EINPROGRESS) {
> retval = 0;
> goto done;
No device driver is allowed to test urb->status except within the
completion handler -- otherwise they're racing with the host
controller driver. Yes?
> Correct me if I am wrong, but it seems to me that a completion handler
> may be running after a synchronous unlink returns.
OK -- you're wrong! See above, for starters. Though I could believe
that some of the 2.4 host controller drivers have bugs in that area,
at least on MP systems. I seem to recall pushing that into the HCD
layer so that related problems could be _structurally_ removed,
rather than only by (excessive) debugging.
> In most disconnect methods we want to free memory completion handlers
> may want to access. Thus a method to wait for them to finish would be handy.
Could you explain why it's hard to actually let the completion
handlers (each driver knows when they're called :) flag that it's
OK to free such memory?
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
