Hello Oliver, On Wednesday 15 January 2003 00:46, Oliver Neukum wrote:
[stop resubmitting in the completion function] > 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. I agree. The usb core API acts like a multiplier. If the API is difficult, there a great difficulties for the device drivers. But I have a problem with usb_unlink_urb() and resubmitting, as you suggests. First of all, usb_unlink_urb() comes in two flavours, asynchronous and synchronous. If I use asychronous unlink, it may well be the aim of the device driver writer to do a resubmit in the completion function as a result of the unlink! (perhaps to implement an external timeout/retry for an urb). And the same completion handler should not be able to do a resubmit if the unlink is synchronous? Your design requires an API function (usb_submit_urb()) to fail because of the context of the call. > 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. Because the completion handler is called as a result of an asynchronous unlink, it should be also called as the result of an sychronous unlink. Same behaviour, every time, please! Of course, the completion handler should know that it was called because of unlink(). So it can avoid a resubmit, and we need no extra device driver specific flags. To avoid races, the unlink function and the completion handler need to have exclusive access to the urb. (Spinlock?). > 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. How do you differ between the two cases? They may be the same. best regards Wolfgang Mües ------------------------------------------------------- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
