> However, a grep of drivers/usb/*.c tells me that most drivers
> ignore the return value of usb_unlink_urb(). That's quite a lot of
> potential bugs ... there's a race. Happens on MP systems (CPU
> #1 is running the HCD's interrupt handler, which calls the urb's
> driver completion callback; C
> > >Therefore the need to do
> > > a synchronous unlink while an asynchronous unlink is happening
> > > may arise.
> >
> > I think I see what you're suggesting, but I'd basically say what I've
> > said before: drivers which are that confused about how they work
> > are really asking for trou
On Tuesday 05 February 2002 02:25, David Brownell wrote:
> With respect to new API entries to distinguish the synchronous
>
> and unsynchronous unlink cases:
> > An asynchronous unlink due to being asynchronous allows other
> > things to happen while it is underway.
>
> Same thing for a synchronou
With respect to new API entries to distinguish the synchronous
and unsynchronous unlink cases:
> An asynchronous unlink due to being asynchronous allows other
> things to happen while it is underway.
Same thing for a synchronous unlink -- except the initiating
thread can't cause them, it'll be
> > 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 c
> > > >> 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
> > smi
