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: [email protected] [mailto:[email protected]] On Behalf Of Robert McGwier
Sent: Monday, April 28, 2014 7:26 AM
To: Marcus D. Leech
Cc: [email protected]
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 <[email protected]> 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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLCProfessor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
