On Tue, 21 Jan 2003, Oliver Neukum wrote: > > > > It would be great if we could eleminate the need for handling unlinking > > > during completion at all. Is there a reason you cannot make them mutually > > > exclusive? IMHO it should be possible to do that if you make it a > > > requirement to call giveback with handler_lock held. > > > > Sure, that could be done. Or even easier, hcd_unlink_urb() could just > > grab handler_lock and hold it all the way up until the call to > > wait_for_completion(). That would eliminate the need for the > > err_out_waiting part. > > It's not so simple. hcd_unlink_urb makes calls down into the hcds which > can block.
I stand corrected. > > But I don't see this as much of a simplification. We would still need the > > handler_lock spinlock. We would still need to track the urb's internal > > state in order to prevent resubmitting unlinked urbs, double unlinking, > > and double submitting. In short, it would only amount to a very slight > > change from what I sent you before. > > It would keep the API completely unchanged, which is a huge advantage. > We'd make sure that you either can still unlink the "old" urb, or you are ready > to unlink the "new" urb. I think I get your point. The whole idea of this exercise is to simplify things for device drivers by giving them an easy way to unload cleanly. There are two issues involved: (1) breaking an indefinite handler-resubmits loop, and (2) knowing when an active urb is done and its handler has exited. The API change we have discussed really just relates to (1). Since it prevents the handler from resubmitting an unlinked urb, it allows a driver to break the loop simply by unlinking the current urb. Quite apart from the fact that changing an existing API is often a bad idea, in a more general setting this change might not be helpful. For example, if the driver maintains a pool of urbs or uses some sort of round-robin submission, then the handler might end up submitting a different urb from the one that just finished. The only foolproof way to break a loop like this is to have the driver set a "stop submitting" flag that the handler checks. In fact, drivers should be doing something like this anyway. (I know David Brownell will agree with that :-) Given these objections, it's probably best not to implement (1). (2) can be done separately. It's just a question of grabbing the handler_lock in hcd_unlink_urb() before the call to acquire urb->lock and then releasing handler_lock immediately after. I'll send in a patch for it later. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
