You know, in all this email I think one of the key issues has somehow not gotten brought out: the need to let the I/O requests get canceled when the task gets signaled. Or at least having an option to do that.
Alan Stern wrote:
On Wed, 12 Mar 2003, David Brownell wrote:
I only put it in the driver because strictly speaking, this needs to be stored as per-interface state rather than per-device. If there's no problem with the core maintaining per-interface data, then fine. It would still require an additional argument to usb_bulk/control_msg(), to specify the interface.
Except for control messages, urb->pipe easily lets you track which endpoint and hence which interface the request is for.
Okay, so the extra argument is only needed for usb_control_msg(). But it
wouldn't hurt to have it for both; there must be a certain overhead
involved in iterating through all the interfaces' lists of endpoints to
see which contains the endpoint of interest. Unless you've added a data structure to speed up that process...
It happens so infrequently that adding new data structures would just slow down the normal paths. They're not really necessary, though if they were in place I'd likely not mind.
Actually the relevant primitive is "unlink all the requests to this endpoint"; they're owned by the hardware, and some of them are likely partially completed. That's the primitive which is generally useful, in the "driver unbind" cases (not necessarily just disconnect) as well as for config changes.
What about requests for endpoint 0? They may have been submitted by several different drivers.
Right, but ep0 isn't busy at all. We don't know that simple solutions like "wait till there are no ep0 requests" have any problems ... though we do know that usually the wait would not be needed! :)
If you mean that nobody has ever needed to cancel just a single synchronous message except as part of cancelling all of them for a disconnect, I agree.
Yes. Same is true when the driver uses asynchronous models too.
Surely you don't mean to say that drivers call usb_unlink_urb() with the URB_ASYNC_UNLINK flag set only during disconnect()?
No. But when would it be appropriate to unlink one request from the middle of an endpoint's queue? At best that's an esoteric and very error-prone case. And a good rule of thumb for designs is to get rid of all such models.
How does your patch know which interface a request is intended for?
Looks at the endpoint addressing information.
Again, what about requests for endpoint 0?
Again, see above. In the rare cases that matters, we have a simple solution that'll work in most cases.
Also, perhaps it would be better to unlink them _after_ disconnect(). That way the driver won't be tempted to try to re-issue the requests when they complete with an error.
That last patch of mine makes submits fail ASAP, even before disconnect() is called ... so "reissue" can't happen, at least in the device disconnect code paths. Reconfig has never worked right AFAICT, needs work still.
Unlinking them _before_ is likely to make some drivers unhappy, but this is a case where I think the cleaner solution is to be preferred ... fewer ways that things can go haywire is Good.
Hmm... I still think it might better be done after. But either way seems about equally clean and reliable. Maybe you're just trading off the possibility of things going haywire in the core against things going haywire in the driver. Of course, neither will actually happen ;-)
Actually, "after" seems less clean/reliable to me, that's what 2.4 ends up doing in certain cases and it's messy. Oopses do happen when that misbehaves.
Which isn't to say it couldn't work -- it's just that since it's more complicated ... so without a clear reason to favor the late unlink, simpler seems better.
- Dave
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
