Hi, On 03/22/2013 01:16 AM, Pete Batard wrote: > On 2013.03.21 20:06, Ludovic Rousseau wrote: >> Maybe LIBUSBX_IMPLEMENTS_DETACH_KERNEL_DRIVER > > Works for me.
I've a small nitpick, lets call it LIBUSB_CAP_SUPPORTS_DETACH_KERNEL_DRIVER to match with the LIBUSB_ERROR_NOT_SUPPORTED error code. >> It would also be cool if libusb_claim_interface() could report a >> specific error in case detach is needed. >> Something like LIBUSB_ERROR_NEED_DETACH_KERNEL_DRIVER. > > I think if we could do that, No we cannot, on Linux failing to claim because another driver is attached gets signalled by -EBUSY which we currently translate to LIBUSB_ERROR_BUSY, changing the error code will likely break existing apps. We could (and should) document that on platforms which have LIBUSB_CAP_SUPPORTS_DETACH_KERNEL_DRIVER a return of LIBUSB_ERROR_BUSY from libusb_claim_interface means that a detach is necessary. > we may not need _detach_kernel_driver() in > the first place. It would probably make more sense to just detach on > device open and restore on device close, If we want to do automatic detach, we should do it on claim_interface, since drivers are per interface, not per device. I know there is something weird on windows where composite devices also have a composition driver though, so we need to think about that part too. > as, if someone wants to access > a device, they probably would prefer to have libusb/libusbx sort the > prerequisites. Although automatic detaching may seem like a smart and user (programmer) friendly thing to do, I'm very much against it! Let me explain why: a) libusb_detach_kernel_driver on Linux will *always* work if the user has the necessary rights on the usbfs device node b) When libusb_detach_kernel_driver is done, the driver sees a device unplug, iow it is to the driver as if the user janked out the device. Combine these 2 and now try to run some generic libusb using tool, on a system with liberally set up usbfs permissions, then the following could happen: i) user is using a usb-stick, copies a large file to it ii) user runs the libusb tool iii) the tool detaches the usb-mass-storage driver before all cached writes are flushed -> data and/or filesystem damage Not good. Now this can already happen, but making the driver detach automatic (by default) makes it that much easier to happen, so strong NACK to that idea. ### Now with that said, we could still try to implement automatic detach, and I'm in favor of it, but, BUT it needs to be something which apps explicitly enable! Assuming all platforms will do auto-detach on interface claim (which makes sense given that drivers are usually per interface), we could make this a device_handle property, so then an app would do something like: libusb_device_handle *handle; libusb_open(dev, &handle); libusb_set_auto_detach(handle, 1); libusb_claim_interface(handle, x); With: void libusb_set_auto_detach(libusb_device_handle *dev, int auto_detach); This function would be available on all platforms and simple store the setting in struct libusb_device_handle, where interested backends can then use it. I think implementing this for Linux should be quite doable. So if we can agree on an API for enabling / disabling auto-detach (as said I don't believe we should do it by default) then I'm willing to take a shot at writing patches for this. > If it was easy, we might have seen a patch proposal for that already. It should not be too hard actually, just nobody thought about auto-detach before AFAIK, since things just organically grew into what we've today. Regards, Hans ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
