I'm excited about some work I've done recently, which I'm calling "uspace+rtai". It raises the possiblity that, with a single linuxcnc binary package we could support a wide range of kernel versions, both RTAI and PREEMPT-RT, with just 200 new lines of code and 1 new object file needed for RTAI.
Since LinuxCNC 2.0, we've had a fairly stable realtime API, called RTAPI. But for a very long time, the only sort of RTOS that worked with LinuxCNC was RTAI, and in this case all the real-time parts of LinuxCNC had to be built as kernel modules. Since the Linux kernel doesn't have a stable ABI, this meant it was necessary to build LinuxCNC differently for each individual kernel -- right down to a single kernel configuration change! This is one reason we're so slow to get packages for new Linux distribution versions. In LinuxCNC 2.7, we finally got "uspace" (which I now mentally think of as "uspace+posix"), a realtime implementation that relies only on Linux userspace APIs and POSIX threads, and which gives good performance on many machines when paired with kernels that have the "preempt-rt" patch set. I built on the experience of (if not directly on the code of) Michael Buesch and Machinekit contributors when I implemented this. This works pretty great, and the same build of LinuxCNC works on a wide range of preempt-rt kernels, all the way from Linux 3.2 to Linux 4.6, without recompiling anything. On the other hand, the systems I've personally tested with "preempt-rt" don't have good enough latency for software step generation systems, with latencies of over 100us (though some report systems that are better), so it's not anywhere near a universal solution. When I wrote uspace, I was aware that RTAI (and, I think, Xenomai) have userspace realtime models; RTAI's is called LXRT. I made some educated guesses about what APIs in RTAPI would need different implementations for different underlying RTOSes, and designed an abstract class (RtapiApp) that would permit different implementations. For a long time, nothing happened; then I became interested in actually finishing the implementation for RTAI LXRT. It seems to be a success: The required code to support RTAI is under 200 lines, and the total diff relative to our master branch at the moment is 14 files changed, 487 insertions(+), 165 deletions(-) Because of the way RTAI's LXRT is designed, it appears that a binary built with a particular RTAI release would work with any kernel version as long as it is patched with a matching RTAI patchset; I haven't done any checking to find out whether the LXRT ABI changes frequently or infrequently between RTAI releases. Enough background. As to the state of my branch, let me anticipate and answer some questions: What do I think works? Any realtime components that use only RTAPI APIs. What have I tested? "runtests", AXIS with a software stepgen parport config, detecting hostmot2 hardware, etc. Base computer: Debian Jessie with Seb's 3.18.0-1-rtai-amd64. What probably doesn't work? hm2_eth and hm2_spi, since they work by Linux syscalls. What probably could work with more effort? I would love to see socket APIs in RTAPI which can either talk to Linux sockets (syscalls) or RTNET. I don't know how feasible this is, and I've never used RTNET in the first place. Ditto Xenomai support, if anybody wants to use that flavor of kernel. In both cases, though, I'm not planning to write it. (But if you want to do this work 'out-of-tree', I will absolutely help structure LinuxCNC to facilitate this; use our issue tracker or this mailing list if you have ideas for that. For instance, my tree is probably close to being able to enable support for a different RTOS to be built with just the linuxcnc-dev package installed) What's left before it hits master? Mostly packaging, reacting to feedback from testers, and getting the permission of Moses in his RM capacity. What might the future hold? I hope that someday we can get rid of kernel modules in linuxcnc entirely. Software bugs in LinuxCNC are less likely to wedge the whole system, debugging is better, and it opens the door to using C++ in components and drivers. (I'm not proposing to break linuxcnc's ability to build kernel modules in 2.8) The code is at https://github.com/LinuxCNC/linuxcnc/pull/108 and is currently being rebased frequently. If you give it a try, I would love to hear your feedback in this thread or on the issue on github. Jeff ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
