I understand that folks are waiting for 'the RTOS gang' to produce something tangible, and in Wichita we asked for some leeway for wrapping up the work. (I said two weeks, meaning 'after I'm home' and that still might hold for a rawhide cut)
This is where we are: Both John and me work intensively on the merge candidate branch, which will be based on Johns github repo branch.*) At the same time Charles has been working on his BeagleBone-related themes (authoritative place to look: http://bb-lcnc.blogspot.co.at/), and there is also some rather interesting work in the pipe by Ian: support for an BB FPGA cape. Thankfully, the RTOS and BB work directions are largely disjoint and can proceed in parallel without much coordination. The current focus of Johns and my work is: - until recent, mostly the build system, which John has worked on, and where he has done incredible amounts of work - currently non-RIP installs are still work in progress - it has turned out that some aspects of configure-time constants need to be mutated into 'depending on flavor selected at runtime' - I have found John's build system work exceptionally stable despite all the changes under the hood (by default, in one go a build for every applicable thread system installed on the build machine will be created, not just a single one as with the rtos-integration-preview* branches) **) - John already has taken some steps towards creating a build which will will be amenable to Debian and other distro's integration ***) - I looked into realtime fault handling - which was not production quality - towards making this more intelligent than just logging the fact it happened; thanks to separation of policy and mechanism in RTAPI there is now a way to customize RT fault reaction through a HAL component, meaning reaction to RT faults is now an issue of dealing with stock HAL and RTAPI API's, not with RTAPI internals - you dont like it: well then change it, comp is your friend. For instance, creating an estop signal if RT faults happen. ****) - I have made a sweeping change this week in the way startup sequencing of the realtime environment works; I justify this change with 'it's going to be all the same for all flavors and much easier to understand and debug'; and it is primarily about reducing the number of moving parts (note the 'change' is minimally new code, but lots of deleted code which is by definition bugfree and easy to support ;) We still believe 'a merge candidate' is viable well within July. As for documentation, the next topic is to write a 'Unified Build/Multiple RTOS Principles of Operations' manual fragment, which outlines the basic setup and flows, and the machinery to build for, and support a number of different RTOS platforms by runtime choice. This should be helpful to folks helping with a code review. I routinely build on the BeagleBone and have no surprises to report, meaning this will be available as a build option as soon as we declare victory. Since the last remnants of inline assembly code are gone, the '--with-platform=<foo>' option really only stays to determine the set of drivers to build. Re the rtos-master-v0 branch in my repo: this represents the sum of work pre-unified build as I have announced my mail to the devlist of May 28 'releases & branching'. I have on purpose not announced this branch for public consumption, but some of that has happened nevertheless (my fault, I need a hard-to-stalk secondary repo ;). There is a high chance this branch (which is a forward merge of existing work) will be thrown away and redone based on the ub* branch. You heard it clear and loud: do not rely on this branch in any way, and do not expect it to be an ancestor of a merge candidate. We currently have no automated way to build BB (and other) kernels. I have gotten in touch with Robert Nelson (debian/bb) and Koen Koi (angstrom/bb) to get something in place and willingness to cooperate is there; I would love to be able to hand over this effort to another caretaker (all these builds happen on my server manually right now, and that server still will be available, but I'd be grateful for somebody else taking over) for 'the gang' ;) - Michael -- *) to give an indication what 'intensively' translates into: these are my additions alone to John's ub branch since monday this week - 35 or so commits: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/ub-reorder-startup-cleaned **) this will require build support downstream to have build machines with all applicable kernels and userland support packages installed, even if running regression tests of course will apply only to the flavors supported by the running kernel ***) while it is true this isnt absolutely essential for a merge candidate, we both have found out that once you are working intensively on a theme (and build support is a complex one) it makes sense to keep going; the loss of context and re-learning once you start after weeks or months is considerable. ****) see http://tinyurl.com/pcx7x5v for an example fault handling comp see http://tinyurl.com/or4xzw7 for a usage example ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
