On 21 March 2015 at 09:46, Alexandru Csete <[email protected]> wrote: > On Sat, Mar 21, 2015 at 9:59 AM, Dominic Spill <[email protected]> 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 _______________________________________________ HackRF-dev mailing list [email protected] https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
