Hi, On 07/28/2012 12:39 PM, Xiaofan Chen wrote: > On Sat, Jul 28, 2012 at 5:54 PM, Hans de Goede <hdego...@redhat.com> wrote: >> Currently applications for devices which only are accessed from >> userspace can use claim / release interface to make sure they >> don't get in each others way. The same however does not work >> for applications which first need to detach >> a "native" / in kernel driver, as this detach will not only detach native >> drivers but also the usbfs driver, thus stealing the device from another >> userspace / libusb app. >> >> This patch fixes libusb_detach_kernel_driver to only detach "real" kernel >> drivers and not the special usbfs driver used for userspace access to >> USB devices. If the usbfs driver is found LIBUSB_ERROR_BUSY will be >> returned. > > Hmm, what if no other applications are using the device and > usbfs is attached to the device? In that case, there should be > no error.
Oh, good call! You're completely right of course, so instead of returning ERROR_BUSY in the case usbfs is bound to the interface we should either return SUCCESS, or ERROR_NOT_FOUND. I've a slight preference for ERROR_NOT_FOUND, as we did not actually detach anything in the case usbfs is bound, and apps should already be prepared for handling ERROR_NOT_FOUND Any proper written app should follow up the detach with an interface claim, and that one will fail with ERROR_BUSY if the interface is actually being used by another libusb app, so the app will get the error when claiming, which is actually the right moment to return the error. As for apps not properly claiming interfaces the kernel will transparently do a claim for them (with a warning to dmesg) and if that claim fails fail any attempts to communicate with the device, so even non properly written apps should not be a problem. I'll do a new versions returning ERROR_NOT_FOUND instead. > Related ticket: > https://github.com/libusbx/libusbx/issues/20 Yes that one would be fixed by this patch. > https://github.com/libusbx/libusbx/issues/17 That one is unfixable without kernel changes, I've been thinking about this race when I wrote the original patch, and I find it highly unlikely it will actually be a problem in practice. Regards, Hans > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
