Plan to allow running LinuxCNC atop Machinekit-HAL

[cerna]

I would like to dedicate this issue to tracking progress, ideas and problems with porting (and running) LinuxCNC@master atop the Machinekit-HAL@master. This discussion was already partially broached in #260, where the main problem was pointed out: There needs to be some consensus on how to integrate LinuxCNC onto Machinekit-HAL so the limitations and consequences for Machinekit-HAL development would be minimal or at least clearly defined.

Given that I heard about it in Machinekit's back channels, it's not something generally discussed here in the open. This is detrimetal to any potential lurker here on Machinekit GitHub or in Machinekit Forum who is preparing to do some (serious) development. This way he can chime in here.

Work on this endeavour was already done by @zultron and @ArcEye. The former can be previewed in https://github.com/zultron/machinekit-hal/tree/mk-hal-lcnc-and-singlemoddir-zultron-pr, the latter is (probably) passé now (author left the project). Other than these two examples, I am not aware of anybody else working on this. (If you are, please, declare this status here.)

[cerna]

I will bite and describe my musing how I would (try to) go around implementing this. I think that it's imperative to keep the distance between Machinekit-HAL and LinuxCNC. Looking at the current state of LinuxCNC community, I see no move towards more modularized approach. Quite the opposite given new functionality is being added on the heap. So the chances of LinuxCNC going the same route and separating -CNC into its own repository/package are slim to none. So any separation would have to come from Machinekit side.

My theory on how to approach this is something along the lines of exporting all real-time scheduled components/drivers into Machinekit-HAL HAL and rtapi_app execution threads and let LinuxCNC run in normally scheduled (SCHED_OTHER) container with all so-called userspace components (which are needed for LinuxCNC run), with the NML communication between modules in Machinekit-HAL and containerized LinuxCNC open/shared. And with ringbuffer/triple-buffer synchronizing the state of Machinekit-HAL HAL and LinuxCNC HAL.

This would also mean to run emcsrv on Machinekit-HAL side with channels for the RT components and (probably) on the LinuxCNC with channels for everything else (and maybe some form of synchronization). I think it could be little similar like the gross hack described here.

Then I image that Machinekit will have a repository with a branch which will track (from time to time) the LinuxCNC@master. I think that it could mean the least-possible-amount-of-work for keeping the LinuxCNC up to date with Machinekit-HAL.

However, question to those who already tried to run LinuxCNC over Machinekit-HAL: Do I completely miss the mark?

[zultron]

As you noted in the description, I did already get this working.

No major redesign of the existing LCNC-EMC to HAL interface was required. Mainly, there are the motion and io modules. Building these against MK HAL is similar to other out-of-tree module builds. The challenge was teaching the LCNC build system to do this: changes in configure.ac and Makefile/Submakefile systems to configure an external HAL rather than internal, and in that case, turning off the build for the local HAL and building motion and io against the external HAL, with properly located C headers and libraries, plus other details. There were a few minor API changes in MK-HAL that broke compatibility, but I determined that these changes could easily be reverted and the extra functionality the changes provided could be implemented without API breakage.

Otherwise, LCNC-EMC on MK-HAL configurations will use the standard HAL modules that come with MK.

NML is the linkage between motion and io HAL modules and the EMC application milltask process. That should all be left on the LCNC side of the split.

Using the line of split that I chose, the updates on the LCNC side were IIRC on the order of a few hundred lines primarily in the build system, and going forward would be very easy to merge with updates to LCNC. IMO the changes are also trivial enough that the LCNC community might maybe possibly be convinced to merge them upstream, and the MK project wouldn't be required to maintain a forked EMC repo at all.

[zultron]

I've been reviving this project over the last few days, and have the two halves building again. Now I'm working through the regression tests failing on the LCNC-side.

One stumbling block is that mentioned in #104 (comment): Some regression tests run halcompile --install foo.comp, but when the HAL module directory is /usr/lib/linuxcnc/modules, that fails with IOError: [Errno 13] Permission denied. This is a minor problem and there are hacks to work around it, but a proper fix isn't so trivial.

[cdsteinkuehler]

I like the idea of a hal component search path, or at the very least, a system and a user path.

[zultron]

@cdsteinkuehler +1

Here's what I'm thinking seems easiest to implement (before actually having tried anything):

• Leave the hard-coded default/system path (/usr/lib/linuxcnc/modules or rtlib/modules)
• Enable optionally configuring a (single) user path with an environment variable
• Leave existing logic enabling full file paths (loadrt /foo/bar/baz.so) unchanged

This would solve the use cases I'm aware of, all of which require the standard comps from the default path, plus one or more comps build out of tree. If someone wants to come in later and change the single user path to a searchable set of paths, they could do that without breaking compatibility.

Comments?