[Hackrf-dev] hackrf_open() failed: HACKRF_ERROR_LIBUSB

[Alexandru Csete]

On Sat, Mar 21, 2015 at 9:59 AM, Dominic Spill <dominicgs at gmail.com> wrote:
> On 21 March 2015 at 03:06, Rick "Zero_Chaos" Farina
> <zerochaos at gentoo.org> wrote:
>> On 03/19/15 06:34, Paul Connolly wrote:
>>> The kernel modules (RX only) for new  SDR devices was known to be
>>> arriving for the HackRF in 3.18 for a while.
>>> http://palosaari.fi/linux/
>>> ... snip ...
>>> AirSpy SDR driver (airspy)
>>> * Kernel 3.17
>>>
>>> HackRF SDR driver (hackrf)
>>> * Kernel 3.18
>>> * only RX
>>> ... snip ...
>>>
>> Is this stuff known bad or what?  Should everyone be avoiding the in
>> kernel drivers?
>
> I'm not aware of any software that interacts with it and it claims the
> hardware as soon as you plug it in, so I think we should all be
> blacklisting it by default.  We may need to look at the possibility of
> installing a blacklist file in to /etc/modprobe.d when we install the
> HackRF tools as this will break for every user when they run 3.18.

There is also the (better?) option to detach the kernel driver. Libusb
has an API call to do this and the rtl-sdr library uses it already if
compiled with with the option. Perhaps a similar option can be added
to libhackrf.


> I'm not sure why kernel developers feel that it's acceptable to break
> the official library/tools associated with the hardware without first
> getting in contact to discuss it.  Maybe in time we'll start using the
> kernel driver, but I don't see that it provides any benefit at this
> stage and using it would remove our ability to make changes to the
> host / firmware interface.

Such changes can always break existing installations regardless of
whether it is a kernel driver or a userspace library. The only
difference is that for most people, including myself, a userspace
library is easier to deal with.

Alex