This is a status report, and a list of open work items of the 'new RT OS common codebase' work, which need completion before a merge.
I will give recommendations and opinion in separate mail, this is just status and open issues. status ------- 1. The RTAI build is essentially untouched and should remain building and working as before (new includes and #ifdefs due to changed configure namespace here and there, but no effective code changes). 2. the 'simulator' build is changed under the configure hood (see below) but on the build level it should look very similar; the only notable difference is that you can build drivers for this with '--enable-drivers'; this at this point means the hal_parport (PC) and hal_gpio (arm/raspberry) which can be exercised in this scenario (this is a not recommended configuration to run a machine, but it makes HAL/RTAPI driver-enabled in case somebody wants to build non-RT applications based on these components, and it is an excellent vehicle to develop userland drivers when you do not have a Xenomai or rt-preempt kernel at hand) 3. xenomai-user style: this code is mostly my integration based on several sources found "out there" in some shape or form (thanks to previous work by Volkan, Sergej, Mungkie). This is the one I understand best, and of the user thread styles it performs best in terms of latency. Build support is in place, passes runtests, and can run latency-test. Raspberry build: RTAPI/HAL works but UI's need work due to OpenGL issues - that is not on my goal list; contributors welcome. See note on Tcl at bottom. 4. The rt-preempt-user code by Michael Büsch and many others has been integrated by Charles and John, and I did some work on polishing and removing duplicated code, some of which remains at this point - it's 'mere work left'. Again build support is in place, it passes runtests, and can run latency-test. Latency is substantially behind xenomai-user. 5. I attempted a straight port of RTAI code to xenomai kernel threads because it looked like 'limited breakage'. It does work with some issues outstanding; however the showstopper is that I found out only after completing the initial code that Xenomai 3 will not support FPU in-kernel, and the kernel threading model I used - and spent about two weeks of lost work on - is a dead end and deprecated. Dead in several years from now, that is, but that is still dead if one is looking for a long term viable base. An interesting fact is that xenomai-kernel does not necessarily have better latency than xenomai-user. 6. 'RT Linux': I did not address this at all. AFAICT it is dead and good to remove (which I did not, but cannot test otherwise). The above work is done in this branch which is forked off v2.5_branch: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/rtos-integration-preview1 I have upward-merged that into master periodically - just to see how that goes - with no undue surprises, that is here: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/rtos-testmerge-into-master (it might lag a bit behind the previous branch) ----> The major limitation of all userland thread styles is PCI driver support. That is not a showstopper for a code merge, but it is on the critical path for all of the userland styles to become a viable base for working with non-parport/gpio hardware, and the issue is isolated in scope but needs determined attention by someone in the know (which I am not, and hope I do not to have to become one). See work items below. User-visible changes: --------------------- explicit binding of threads to CPU's can be done all-clever-all-automatic or manual. I went for manual at this stage because the impact needs yet to be verified, and Kent's observations confirm that. Hence the threads and motmod modules now have optional cpu1= cpu2= ... parameters, and the default is to 'behave as before'. It's documented in the man page. Important developer-visible changes: ------------------------------------ Userprocess RT threads are _much_ easier to debug than kernel threads styles - note even with Xenomai userthreads (which is closest to RTAI in design), it is still possible to debug an RT thread (or a segfault in same for example) with gdb as always; it just will become a non-RT thread once it drops into gdb. It has always been possible in the simulator build and the components it supports (i.e. not drivers), but the usage range is widening as drivers appear in userthreads. I am not sure folks developing components appreciate, or in fact are even aware of the option of debugging components with gdb if a userthreads style is chosen (like --enable-simulator); when we have PCI shim support, that should be possible even for PCI drivers (hows that for a selling point for making life easier - debug a driver without bringing down the house?) ------------------------- The following is more targeted to the developer/build infastructure involved. HAL/RTAPI changes at the OS-independent layer --------------------------------------------- HAL and RTAPI needed minor mods (HAL create_threads needs to pass on the HAL thread name as Xenomai identifies threads by name; also explicit cpu parameter added). That will not impact many, just a note why it came about. RTAPI atomic operations: this so far was inline assembly for x86 only. Since gcc nowadays has portable builtin atomic operations for most if not all architectures, on non-386 platforms the gcc builtins are used. See src/rtapi/rtapi_bitops.h . Build test kernels ------------------ Everybody wants to use a 'stock kernel', but that is just nice grey theory - and the RTAI kernel we have is compiled without module versioning support because this breaks module loading. That is a requirement for kernel modules, and hence xenomai-kernel builds too, so the range of 'stock kernels' available for those scenarios is currently zero, and likely to remain so. I therefore went to build rt-preempt and xenomai kernels myself, and I hold the complete code and kernel configs here: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git . I made sure I recorded every single config change and the code base is up to date; I note that the current RTAI kernel package has no exactly corresponding source package and I wanted to avoid that situation to recur at all cost. There are packaged kernels at http://static.mah.priv.at/public/xenomai-debs/ . These are the ones I use, and some folks use them to track this work; I am Mr Clueless about debian packaging and do not pretend or hope to become one, so this might not be production quality and 'the way it should be done'. I do need help here before these are let loose onto others. I use shell scripts under linuxcnc/* in these branches to build the kernels. Xenomai/ipipe tracing: tracking bad latency figures: ---------------------------------------------------- Xenomai has the option of compiling the kernel with 'ipipe tracing', and I understand it can be used to track down causes of latency hiccups. I built such a kernel and tried it, but I lack the clue to make sense of results. It is an extra tool in the drawer if needed though. An ipipe-trace-enabled kernel is also in http://static.mah.priv.at/public/xenomai-debs/ . Xenomai userland support: ------------------------- This is a package needed (for linking userland RT applications, docs, demos etc). Bad news: it needs a non-default build option to nicely cohabitate with Python module import (yes..), so I track my own: http://git.mah.priv.at/gitweb/xenomai-linuxcnc.git/shortlog/refs/heads/linuxcnc-v2.6.1 . Again, see /linuxcnc and branch history for hints. Build taxonomy and targets -------------------------- Configuration is divvied up along the following lines: - which thread model is used (RTAI, Posix, xenomai-user, rt-preempt-user, xenomai-kernel) this is set by the configure '--with-threads=<style>' option and results in a series of #defines in config.h and corresponding string replacements in Makefile.inc, Makefile.modinc and rtapi.conf: RTAPI_POSIX RTAPI_RTAI RTAPI_RTPREEMPT_USER RTAPI_XENOMAI_KERNEL RTAPI_XENOMAI_USER - the answer to the previous question decides wether threads run in kernel or user space, and hence how modules are built - as kernel objects, or userland dynamic shared, resulting in BUILD_SYS_KBUILD or BUILD_SYS_USER_DSO - whether to build drivers. This is really relevant explicitly to --with-threads=posix - the historic 'simulator' build now is just a Posix threads build without drivers. If you use --with-threads=posix and --enable-drivers the symbol BUILD_DRIVERS is defined; purpose - to work on userland drivers or do non-RT/non-Linuxcnc HAL/RTAPI apps. - whether 'sudo make setuid' is needed. This is needed if a userland thread style is used, and drivers are requested (implicitly with rt-preempt-user and xenomai-user; with posix only if --enable-drivers was given). In this case rtapi_app needs to become setuid root so it can gain I/O permissions. - which platform to build for. That is new because we didnt have that choice before. Right now we can do --with-platform=PC and --with-platform=raspberry . - CPU architecture. that is in a sense new too since we only had x86 flavors so far. I have relegated this to the symbols defined by gcc, like __arm__ , so there is currently no configure option. - which kernel this is built for. I tried to make this more portable than before; be default it is for the running kernel and the properties are detected by investigating the symbols in the kernel config; that is /boot/config-`uname -r` or /proc/config.gz if that exists. The result of this will set the kernel thread style (defaulting to xenomai-user in the xenomai case because also xenomai-kernel would be possible). As for the historic mess of doing some of the configuration through make/cc flags, and some through config.h symbols: my decision was that _every_ config-affected piece of C/C++ code should include config.h and consequently fuzzy cc flags like -DSIM and -DSIMULATOR are gone. Please stick to it. Build runtests: --------------- I have discovered by accident that if you run a xenomai kernel, you can runtests a build for rt-preempt just alike (and of course posix). This might save a reboot. Architectue and platform ------------------------ Since there are new choices here, Makefile and Submakefiles make use of corresponding symbols to drive the build. Open work items =============== Everybody please reappear from under their desks.. we have: PCI support for userland thread styles. --------------------------------------- we *urgently* need a shim layer to map the kernel PCI environment such that existing drivers can be made to work without extensive rewrite. The goal of this work item is roughly this: - survey the existing drivers for PCI support needs - evaluate the existing RTAPI PCI code (see src/rtapi/rtapi_pci.*) - evaluate upci.c/h and outside sources like libpci or libpciaccess if that is some help, and integrate if it does - develop a shim (include file and maybe some support routines) to get away with a conditional include and maybe a library - make sure the result works and develop testcases for common hardware if possible - note changes were made to hal_vti and hal_motenc to use rtapi_pci but I am fairly sure this is untested and broken. I think this is possible, attainable in finite time, and I would be very grateful if somebody else could pick that up and deliver. Debian packaging ---------------- This is badly needed for pushing things through the buildbot and producing deliverables We need somebody with understanding of /debian to fix this up (this aint me) This is likely not a lot of work and I really appreciate if someone could pick that up. Buildbot support: ----------------- This requires: - picking and building kernel - building the xenomai userland support package - wrapping debian packaging of this branch. I fear the set size of addressable persons for getting these prerequsites into the buildbot is 1.. Open issues ----------- Xenomai userthreads (at least) has an issue with TCL at least as per 10.04 TCL state of affairs. The error message is roughly 'TCL: cannot start notifier thread' and it breaks axis_manualtoolchange for me. axis_manualtoolchange could be replaced by a GladeVCP tab easily but it seems this is a old and reappearing TCL gotcha. I dont know how to go about it; my personal solution is probably known - get rid of TCL as fast as you can. A closing remark. The issue on the table is wrapping up and integrating. We had sufficient unpackaged 'proof of concept' in this area, it is now down to the not-so-fun chores of getting it out the door. So, on the open work items, the style of contributions I'm encouraging is 'the whole nine yards', nonwithstanding contributing patches of course. I am not suggesting that a merge and build will result in several workable new options right away. So a merge of this code base is not 'a release'. Rather, at this stage of affairs, the goal realistically can only be to round up the disparate forks and efforts in the wild into a common code tree so work can continue on a standard patch basis and without keeling over the boat. - Michael ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
