Detach kernel driver

[Peter Stuge]

Michal Demin wrote:
> If i do it the other way around:
> 
> if (libsusb_claim_error()) {
>   libusb_detach()
>   libusb_claim_again();
> }
> 
> There is the same "window of opportunity" for different application
> to jump in. Between detaching and claiming the device. (as the
> system is fully preemptive, etc etc ...)

Yes, it's not perfect. But if claim fails twice I think it's
acceptable to error out and let the user sort out her system.


> The API of libusb-1.0 doesn't provide facility to test whether "usbfs"
> is using the device or other driver (there used to be way to read
> driver name in libusb 0.1).

Yes. libusb does not offer a very comprehensive API for kernel driver
management and I can't help but feel that this is a good thing. It's
not really the problem libusb wants to solve. But I also recognize
that the current state of affairs is not so convenient with devices
which can bounce between different kernel and userspace drivers. I
think libusb can't really solve the problem all on it's own, I think
that it also needs some rethinking of what kernels do, but making
significant improvements in this area requires a competent and
dedicated engineering effort..


> The only solution to this problem is not to have the DVB-t module
> present or have the module blacklisted and load it when necessary.

I disagree: Using the code you outline above you will have success if
the module is loaded but the interface is not being used and you have
rights to detach the module driver. (Use udev to give your user
these, so the application doesn't have to run as root.) You will also
have success if no driver at all is currently bound to the interface,
as is the case if a program calls libusb_release_interface() and then
exits (without _attach_kernel_driver()).


//Peter