Re: [Libusb-devel] Patch: libusb/os/linux_usbfs.c: Distingush between usbfs and other kernel mode drivers

[Xiaofan C. <xia...@gm...>]

On Thu, Oct 7, 2010 at 1:08 AM, Uwe Bonnes
<bo...@el...> wrote:
>>>>>> "Alan" == Alan Stern <st...@ro...> writes:
>
>    Alan> On Wed, 6 Oct 2010, Xiaofan Chen wrote:
> ...
>    >> If there is a kernel driver attached to the USB device (an
>    >> interface), then libusb_claim_interface() should fail. And this is
>    >> consistent with my view that "usbfs" is not a kernel driver in the
>    >> context of libusb.
>
>    Alan> If another program has claimed an interface, then
>    Alan> libusb_claim_interface() _will_ fail.
>
> But
> libusb_detach_kernel_driver()
> libusb_claim_interface()
> will succeed.

Ah this is the problem for the libftdi mailing thread.
http://developer.intra2net.com/mailarchive/html/libftdi/2010/msg00618.html

> It would be a good thing, if we could distinguish if the kernel driver is
> usbfs or something else. For libftdi, we could unload ftdi_sio, that was
> nearly always loaded when the device was plugged in, but stop the
> application when some other libusb application already claimed the device.

BTW, it is actually not true that ftdi_sio is always loaded. I've
seen some FT2232x JTAG device which specify (in the EEPROM)
not to use VCP (but D2xx) driver in either one or two the interfaces.
In that case, it seems to me Linux kernel is smart enough
not to load ftdi_sio driver to the interface.

> Libusb-0 usb_get_driver_np() exposed the kernel driver name to the
> user, libusb-1 doesn't. My proposed patch wouldn't reimplement
> usb_get_driver_np but changed the return value of
> libusb_kernel_driver_active(). But it was only a proposal,
> libusb_kernel_driver_active() could perhaps also return the name.

That is my proposal as well.

> This procedure has known races, but probably thats the price to pay for
> user space versus a kernel driver.
>
> Please let me know if I should work out the problem deeper.



-- 
Xiaofan