On Fri, 17 Jan 2003, Oliver Neukum wrote: > I've been thinking somewhat especially about David's points of criticism. > Perhaps I am overdesigning.
It can't be that much of an overdesign. You've only added a state variable and a spinlock. > Would a spinlock held during a call to the > completion handler and while hcd_unlink_urb() holds urb.lock combined > with a retest and retry if urb_dequeue() fails, be sufficient ? I don't follow you here. Are you asking if the internal_state variable could be eliminated in this way? And what's the point of retrying if urb_dequeue() fails? Doesn't that just indicate some sort of bug in the low-level HCD? I think with careful planning, yes, internal_state might be removeable. After all, much of its meaning is already duplicated within urb->status. The problem is that urb->status can't distinguish between COMPLETING and IDLE, since it isn't supposed to change upon return from the completion handler. I suppose we could make this distinction by testing whether or not handler_lock is locked. So if we just choose some otherwise unused pair of codes (like -ENOEXEC and -ECHILD) to represent synchronous and asynchronous CANCELED, then internal_state would become unnecessary. Overall though, I don't believe that your last patch can be simplified very much. Alan Stern ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
