Hello,
Attached are 2 patches: 1 - Try to detach kernel driver from device, when kernel driver present. 2 - add rtl_tcp binary to gitignore.
Michal Demin
Michal Demin wrote:
Subject: [PATCH 1/2] Detach the device kernel driver when kernel driver loaded.
..
@@ -689,6 +690,15 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
libusb_free_device_list(list, 0);
- if (libusb_kernel_driver_active(dev->devh, 0)) {
// reattach laterdev->reattach = 1;if (libusb_detach_kernel_driver(dev->devh, 0)) {fprintf(stderr, "Error detaching kernel driver \n");goto err;}- }
- r = libusb_claim_interface(dev->devh, 0); if (r < 0) { fprintf(stderr, "usb_claim_interface error %d\n", r);
This is racy. It's better to call libusb_detach_kernel_driver() when libusb_claim_interface() returns an error.
//Peter
Hi Peter,
I don't really see the problem.
Ether kernel had the driver loaded, or there is other app. If there is kernel I detach the kernel driver and the device is claimed. If other app is using the device then I will only try to claim. (Which will fail)
I can only see the "racy" when 2 applications are concurrently trying to claim the device, in which case not even your solution is perfect :-)
Could you please be more specific with the problem?
Md
On Mon, Apr 23, 2012 at 7:11 PM, Peter Stuge peter@stuge.se wrote:
Michal Demin wrote:
Subject: [PATCH 1/2] Detach the device kernel driver when kernel driver loaded.
..
@@ -689,6 +690,15 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
libusb_free_device_list(list, 0);
- if (libusb_kernel_driver_active(dev->devh, 0)) {
- // reattach later
- dev->reattach = 1;
- if (libusb_detach_kernel_driver(dev->devh, 0)) {
- fprintf(stderr, "Error detaching kernel driver \n");
- goto err;
- }
- }
r = libusb_claim_interface(dev->devh, 0); if (r < 0) { fprintf(stderr, "usb_claim_interface error %d\n", r);
This is racy. It's better to call libusb_detach_kernel_driver() when libusb_claim_interface() returns an error.
//Peter
Michal Demin wrote:
I don't really see the problem.
Between the time you check for a driver and claim there's a window of opportunity for another driver (usbfs or other) to attach. Best just try to claim and on suitable error try to detach, then try to claim again.
If other app is using the device then I will only try to claim. (Which will fail)
False and false. :) If another app is using the device, the kernel driver "usbfs" is active, and you will detach it, kicking the other app out. Then you will claim successfully if the other app does not try to claim again.
If you try to claim without first detaching, the claim will fail.
//Peter
On Mon, Apr 23, 2012 at 10:57 PM, Peter Stuge peter@stuge.se wrote:
Michal Demin wrote:
I don't really see the problem.
Between the time you check for a driver and claim there's a window of opportunity for another driver (usbfs or other) to attach. Best just try to claim and on suitable error try to detach, then try to claim again.
There is no way to differentiate between errors. In my test I always get error -6 - LIBUSB_ERROR_BUSY. So no such thing as "suitable error" exists.
If other app is using the device then I will only try to claim. (Which will fail)
False and false. :) If another app is using the device, the kernel driver "usbfs" is active, and you will detach it, kicking the other app out. Then you will claim successfully if the other app does not try to claim again.
If you try to claim without first detaching, the claim will fail.
//Peter
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 ...)
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).
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.
MD
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
-
Michal Demin -
Peter Stuge