It just needs an USB2.0 USB to SCSI bridge.
Do they really exist? And will usb-storage use those capabilities? :)
And assuming they did, killing all the requests on that endpoint at once would do what I think you're suggesting: kill a single SCSI request, like "start this write". They wouldn't kill another SCSI request.
Network timeouts ... if the link times out for one packet, there's no way it'd be accepting the next N in the queue. So the same thing applies: no reason not to kill them all.
True, but not all URBs may relate to output. Suffering a timeout on output doesn't mean that all input URBs have to be canceled or status reporting URBs have to be dropped.
You missed my clarification that the primitive applies to the endpoint's I/O queue, not to the whole device (or, which was the point, just one request at any point in that queue).
Furthermore we already have an endpoint where killing all URBs is definitely wrong, EP 0.
Not when the device is disappearing it isn't. But in other cases, there are at least simple solutions like preventing new submissions or timing out requests (5 seconds, per spec) to force the endpoint queue to empty.
Is there really a large benefit in bringing this assumption into a generic API?
Yes. Without a "kill all requests on this endpoint" primitive, there's no way to guarantee configurations are changed safely. That one actually needs a particularly hard "kill", where the endpoint would get re-initialized before it's enabled again.
- Dave
-------------------------------------------------------
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
