I suspect that 10GigE works just fine. It is PCIe and PCIe express that will have the "unique to a kernel release" issues.
Again, as I said before, if you have no idea why you would need PCIe, DON'T DO IT. Use 10 GigE. On Mon, Apr 28, 2014 at 10:39 AM, Lapointe, Benjamin - 1008 - MITLL < blapoi...@ll.mit.edu> 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) > > _______________________________________________ > 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)
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
