> The best way, IMHO, would be to prohibit it altogether.
> E.g. if URB is submitted (returned from usb_submit_urb
> successfuly), then it cannot be unlinked until completition
> is called [see note about cancel below].
Pete, if that's effectively suggesting that usb_unlink_urb()
be removed from the API, I think that proposal is basically
a nonstarter ... so I hope that's not what you mean to say! :)
But I'm curious what you meant about "cancel"; seems like
you think "unlink before completion" != "cancel", while I see
no difference except the name.
> Based on the above, I think that unlinking and completition
> cannot work together as long as they abuse urb->status to signal
> if the urb is referenced.
If access or modification of urb->status were consistently
protected by grabbing urb->lock, I'd think that suffices.
(Some device drivers reference urb->status unsafely, but
that's not a problem caused by the HCD...)
> I have no idea if any drivers try to unlink submitted URBs.
They do. For example, each driver's disconnect() routine
pretty much has to do that. (Though I made a comment
recently that I think khubd should reorder its notifications,
removing many problem cases... if that's done, then device
drivers wouldn't need to do this.) The usbcore synchronous
APIs for control and bulk requests use unlinking when they
time out ... including the usb-storage versions.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
