Detach kernel driver

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.

Michal Demin michal.demin at gmail.com
Mon Apr 23 22:22:57 UTC 2012


On Mon, Apr 23, 2012 at 10:57 PM, Peter Stuge <peter at 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




More information about the osmocom-sdr mailing list