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 builds'). 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 phase. 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 work': 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 Beaglebone - 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. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
