Separate transfer allocation and submission

Leads to some hefty API changes. Now we're much more similar to the
Linux kernel model.

Problems with dealing with asynchronous control transfers are passed
on to the user, basically you must allocate a buffer, start with the
setup, and put the data after. This won't make much sense until
documented (soon...)

1 files changed, 12 insertions, 13 deletions

diff --git a/TODO b/TODO
index ddf3439..fdc72e8 100644
--- a/TODO
+++ b/TODO
@@ -1,9 +1,6 @@
-high priority
-=============
-cancellation race concerns - better tracking of kernel feedback?
-
 for 1.0
 =======
+cancellation race concerns - better tracking of kernel feedback?
 API docs
 isochronous endpoint I/O
 thread safety
@@ -11,19 +8,21 @@ abstraction for cross-platform-ness
 error codes
 fixme review
 
-for 1.1 or future
-==================
-optional timerfd support (runtime detection)
-notifications of hotplugged/unplugged devices
-use poll() rather than select()?
+add some libusb_transfer flags:
+ - treat short transfers as errors
+ - unlink behaviour control
+ - setup packet prepends data (no copying needed)
+ - update timeout with time remaining
 
 1.0 API style/naming points to reconsider
 =========================================
-
-struct libusb_(bulk|control)_transfer or parameters?
 devh in general
-separate transfer allocation and submission
 config struct/function naming
 typedef _cb or _cb_fn or _cb_t?
 typedef as-is or pointers? libusb_dev_t rather than libusb_dev *?
-remove "_transfer" from libusb_{control,bulk}_transfer_request?
+
+for 1.1 or future
+==================
+optional timerfd support (runtime detection)
+notifications of hotplugged/unplugged devices
+use poll() rather than select()?