Ben, That card is very mainstream and uses an Intel driver so I'd expect good support from the get go on 14.04. -Ian
On Apr 28, 2014, at 7:39 AM, "Lapointe, Benjamin - 1008 - MITLL via USRP-users" <usrp-us...@lists.ettus.com> wrote: > Does the 10 Gigabit Ethernet PCI-express adapter card sold by Ettus work with > Ubuntu 14.04 LTS? From the previous discussion, it sounds like the PCIe > interface does not work with the new kernel, but that 10GigE might work. > -Ben > > From: discuss-gnuradio-bounces+blapointe=ll.mit....@gnu.org > [mailto:discuss-gnuradio-bounces+blapointe=ll.mit....@gnu.org] On Behalf Of > Robert McGwier > Sent: Monday, April 28, 2014 7:26 AM > To: Marcus D. Leech > Cc: Discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] X300 PCIe issues > > It needed to be said, but my only goal is to > > ACCEPT AND LOVE 10GigE until and unless you demand the low latency afforded > by the PCIe interface. The things I am working on demand that we meet the > tight timing requirements of open specification waveforms. PCIe was > required. The x3x0 series are major accomplishments for Ettus and should > they just get past the major changes that 14.04 LTS and then BE EXPLICIT > about which kernels they will support, etc. They should be good until the > next LTS comes out. > > Bob > > > > On Sun, Apr 27, 2014 at 5:48 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 04/27/2014 05:32 PM, Sylvain Munaut wrote: > While the "top side" API is > very stable so that applications hardly *ever* experience API changes > that require on-going tedious maintenance, the same cannot be said of code > that runs in the kernel. Quite the contrary. Linus and friends > *routinely and regularly* change critical APIs within the kernel, > sometimes even across minor version revs of the same codebase. > Come on, it's not _that_ bad ... > > Kernel API are stable inside the maintenance release, so they can only > change like every 2 month at most. > > And when they change, finding the relevant commit is pretty easy with > git and it will show exactly what need to be changed in your driver > (because that commit fixed every other driver in-tree for the same > change). And searching LKML will also give all the gory details. It's > like half a day or one day of work at the most. > > So 1 day of code maintenance every 2 month to keep your codebase > current is not what I'd call a nightmare. > And if you want to avoid even that, just get your module merged > upstream, it will be adapted for you free of charge when APIs change. > > And wrt to maintaining the same code building for several kernel, > that's just the wrong approach. Just maintain different version in > different branches. When the code is well written, the driver specific > part will be decoupled enough from the kernel api part that there will > hardly be any conflicts. And when your driver "core function" doesn't > change (and for the NI driver, it seems it hasn't changed it's > functionality for a while AFAICT, just added new kernel support, but I > could be wrong on that), then it's even easier to just release a new > code for each new kernel. > > For only a few revisions appart, you might be ok with #ifdef, but if > you're trying to go back to ancient times, like the NI module which > seems to support 2.6.0 (that's 11 years ago !!!!), yeah there is > going to be some serious changes ... > > Cheers, > > Sylvain > > > PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver > for a FPGA board, so I did experience that. > > So, would we accept an applications-layer API that changed roughly every two > months? I would argue, no, we wouldn't. But > people developing in kernel land seem to accept it as some kind of > necessary gospel. I reject that notion. > > Just because kernel-land is where "all the kewl kids play" is not a good > reason to break things on a regular basis. > > Anyway, this thread is now going fairly far afield.... > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > Bob McGwier > Co-Owner and Technical Director, Federated Wireless, LLC > Professor Virginia Tech > Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY > Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) > _______________________________________________ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
