Your comments have given me a new idea.
The major purpose of adding the facility to cancel synchronous messages is
to allow drivers to unlink the corresponding urbs during disconnect(). Okay, so let's keep the existing API pretty much as it is, but add an
additional argument to usb_bulk/control_msg(). This extra argument will
be something like a list_head; the driver can store the structure in its
per-device data.
I think that's not really necessary since usbcore has its own per-device state. If the goal is to to simplify driver tasks, no need to give them new requirements here.
Then we just have to
add a function that can be called during disconnect() to cancel all the
messages on the list, say usb_unlink_msgs(). That solves the problem in one fell swoop, while adding a minimum of additional complication.
I like the idea of a usb_unlink_all() primitive for several reasons, mostly because the current usb_unlink_one() style primitive is very complex: it has way too many strange and error-prone cases. When there are N requests queued, there are way more than N sequences in which they can be unlinked, some if which are a lot more demanding of the HCD (error paths etc).
And as near as I can tell, nobody has ever needed usb_unlink_one() like we have today, except as a way to build usb_unlink_all().
And yes, that patch I've got somewhere pending (others in the queue
ahead of it) basically makes usbcore do the equivalent of unlink_all,
("all requests on this interface") before disconnect().(Which reminds me of a completely off-topic question: How do you pronounce "isochronous"?)
"iso". ;)
However, it's not clear to me that your approach solves this problem either. Your approach is:
thread 1: (b) create/export usb_sg_request (a) initialize request (c) submit/wait
Actually more like (a) create/init, then (b) export. That's the design in any case, drivers can always add synchronization bugs. (And come to think of it, maybe that's what usb-storage is doing. I noticed it was pre-allocating the request in shared state, and don't remember if there was synchronization when request becomes cancelable.)
thread 2: (d) cancel the request
What's to prevent (b) (d) (a) (c)? That's going to be just as bad.
What's to prevent it is drivers following the basic rule that un-initialized data structures must NEVER be exported to other threads ... never doing (b) export until (a) create/init is done.
- 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
