Chris Dickens

I don't understand the purpose of this interface? Closing a device implicitly releases all interfaces already. What does this gain?

I think I understand now. You are referring to closing a device that has claimed one or more interfaces and the user has set auto-detach on that device? If so,...

> "any interfaces that were auto-detached and only those interfaces". Since the auto_detach_kernel_driver flag is the same for all interfaces, if it is set, you will have to free all...

I don't know that there is anything we can change in this version. Changing the return type from int to enum could break ABI on some compilers.

The semantics of how `transfer->callback` is used/checked are strange. Plus this new behavior isn't documented anywhere in the API. If there needs to be a special "post-submission" callback, I'd like...

Why limit this feature to just the serial number? It would be useful to query any of the three string descriptors that the device descriptor references (manufacturer, product, serial number).

Will be part of the next release. Unfortunately it is a complicated set of changes. Regards, Chris

I am in favor of gracefully aborting all the outstanding transfers during `libusb_close()`, but the only safe thing to do is forget about the transfers entirely. Calling the callback, freeing...

If I understand correctly, is the proposal to have a single `libusb_device_handle` per device that gets created on the first call to `libusb_open()` with subsequent calls to `libusb_open()` returning the...

I was hoping that what I wrote was _not_ your proposal, and it doesn't sound like it is. I'm all for approach 2--I think it is a good enhancement.