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