I would like to clarify some issues raised recently.

What we have since half a year is master and v2.5_branch-based branches which 
build on RTAI, Xenomai, RT-Preempt and of courses standard kernels (aka 'sim 

What we do not have is the flow to produce packages from those branches. 
However, many people have successfully built one or the other flavor, and the 
history of these branches shows exceptionally few fixes since many months 
(there are many changes due to forward merges, but those dont really count wrt 
to stability assessment).

Even if we had that build infrastructure, what these branches imply is that a 
plethora of packages would need to be built - one for each RT operating system. 
This is not only complex from the build perspective, it is likely very taxing 
on those folks which will have to support this and wade through the post-merge 
fallout. That be mostly me, John, Charles, and the occasional contributor(s), 
based on my observation being that there have been very few comments coming 
back from long-time developers with a single exception. This brings me to the 
conclusion that we might be rather alone in the initial post-merge support 

Merging these branches might have made sense a few months back. However, time 
has progressed and so has development based on these branches, with the goal of 
building a unified binary package which runs configurations unchanged on any 
operating system; the only requirement being to boot the desired kernel. This 
work is reaching usability, and I do expect that we will have something to show 
in a few weeks. 

I am happy to report (really on John's behalf, who despite prodding has been 
too moderate to say so publically so far, even if he did most of the build 
support) that a unified binary build runs as planned and does in fact work. 
There are lots of corner cases to cover, but it is not a question any more if 
this will work or not - it will.


While there have been - somewhat sudden - suggestions to basically merge 
whatever happens to be currently around after several months of silence, I do 
not support these for several reasons:

The first reason is that the build economics will improve drastically with the 
unified binary, there will be only one package per distribution and that is it, 
period. So given that we dont have the build flow to do the complex per-flavor 
builds, and the simplified unified build is around the corner, it evades me why 
one should go through the intermediate multiple-package mess to start with.

The second reason is support economics. Since there is fallout to be expected 
after bringing this code into mainline, including documentation, fixes, 
handholding, explaining - the whole rigmarole - I would ask to have our desire 
respected to do this once only, especially if it is rather clear that doing it 
twice in short succession has no dramatic upside but will be quite taxing on 
our time.

The unified binary will be it as far as my engagement in basic operating system 
plumbing goes, this has been a much longer and more intense effort than I 
initially assumed and it has been taxing for John and Charles too. It also 
depletes my list of what needs to be done urgently at that level, whose number 
1 line in 36pt font was 'get rid of this suicidal RTAI dependency', and the 
urgency has not changed as time progressed; rather to the contrary.

This has been achieved, what is left is polishing.

I will support this and make it work properly like I have done with the 
remapping work, but I do not have any plans or pressing itches for any more 
radical changes at this level anymore. I am looking forward to turn to the 
issues on my second list.


As for 'what branch will be merged, the v2.5_branch or the master branch based 

I have left on purpose the window open to branch a new RTOS branch off 
v2.5_branch for several months, and have suggested repeatedly to form an 
educated opinion, given this is a question which has many dimensions - it is 
not just 'well just lets dump this into master'. 

That has not led to tangible feedback, so to end this hiatus I will from now on 
concentrate all work on the master-based branch and drop all work on 
v2.5_branch based branches.

I will also bring forward into the unified binary the following pieces of work 
which are currently littered over several branches:

- Charles' PRU stepper for the Beaglebone, plus some support tools for the 
- Ian's Beaglebone GPIO driver
- Raspberry bits and pieces, namely the SPI driver used for picnc, which will 
be useful as a base for other work (as requested here today)
- Sergey's emcweb work. This need polishing and documenting, but is a nice 
starting point for further web-based interfaces (the longer-term work I am 
doing will have a websockets/JSON interface to HAL which is lacking in emcweb; 
this already works 'in principle'; if there are JavaScript cracks out there - 
please report back, there's creative work to do)

There will be a few pieces of code which will slip in which I had originally 
intended for the longer term HAL messaging/split-RT-from-User-Interface work; 
this means some additional HAL functions and RTAPI ringbuffer support, but this 
does not bring any user-visible or API changes except from multi-instance 
support which will be included in the universal binary and brings additional 
command line options.


As for 'with which distributions should we use' - let me amend the question a 
bit here.

What we had so far was a piece of software which would never ever have made it 
into one of the major distributions if RT support is included, primarily due to 
the reliance on RTAI, but also due to practices which might not be compatible 
with major distro requirements. That starts with kernel module pathnames and 
doesn't end there. Given that, the only option was to build a LiveCD as a life 
vest, and that of course requires a packaging decision.

That is not a given any more. The unified binary will run as-is on any vanilla 
kernel of any reasonable distro, but if the RTOS-specific support files are 
loaded - likely as packages too, maybe also included in the main package - it 
will run on any RT kernel.

This means that the base unified binary package now does have a chance of 
slipping into major distros, and that we did not have so far. I would think 
that takes the pressure of having to roll our own liveCD a bit, and makes the 
'what distro' question not as meaningful as it was. So it makes sense to 
mentally turn a page here.

- Michael

Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
Emc-developers mailing list

Reply via email to