[Hackrf-dev] hackrf_open() failed: HACKRF_ERROR_LIBUSB

[Dominic Spill]

On 21 March 2015 at 09:46, Alexandru Csete <oz9aec at gmail.com> wrote:
> On Sat, Mar 21, 2015 at 9:59 AM, Dominic Spill <dominicgs at gmail.com> wrote:
>>
>> 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.

Yes, that is certainly an option which may provide a useful user
experience as and when there are applications that use the kernel
driver.  However, I was under the impression that the feature wasn't
available in older versions of libusb which are still packaged by some
distros.  If I'm wrong then I'll look at getting a patch in to
libhackrf this week.

>> 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.

It's unlikely that a competing userspace library will stop ours from
working, tools would simply choose which one use, however the kernel
driver takes priority over our library.  It's not so much the
unofficial driver that I object to, it's the automatic assumption that
it's the default one.

I'm personally a fan of userspace drivers/control libraries, and
healthy competition between projects can be a great thing.  For
example, I think SoapySDR is an interesting project to watch
(https://github.com/pothosware/SoapySDR/).

Thanks,
  Dominic