HAL API modernization: out-of-tree drivers that will need porting

[grandixximo]

The HAL types and isolation work in #4247, plus the hostmot2 migration in #4369, changes how C/C++ components register and access pins and params: opaque refs with hal_get_*/hal_set_* accessors instead of direct volatile pointer dereference. The old API still builds (deprecations, not removals), so this is a migration window, not a flag day. Two groups need nothing: .comp files (halcompile regeneration handles it) and pure Python userspace components (the Python API is unchanged).

I searched GitHub for out-of-tree consumers of the C API. In ascending order of notoriety, these will need porting:

• wafaer/SoemMitionDevelop: SOEM-based EtherCAT motion
• rene-dev/stm-hal: STM32F4 USB HAL component
• tinkercnc/spi-fpga-driver: Mesa FPGA cards over RPi SPI (hm2_rpspi)
• ftkalcevic/hidcomp: USB HID input component
• ExcessiveOverkill/universal-IRC-1: 6-axis robot arm control
• jamwaffles/linuxcnc-hal-rs: Rust HAL bindings; wraps the C API, so every Rust component rides on this
• Expatria-Technologies/remora-flexi-hal: Flexi-HAL fork of Remora
• dbraun1981/hal-cia402: CiA402 drive state machine (.comp, probably a free rebuild)
• scottalford75/Remora: STM32/RPi motion boards (NVEM, EC500, ...)

Smaller userspace pieces (VFDs, serial IO) are mostly Python and unaffected; any written in C join the list. Machinekit tracks its own HAL and is out of scope.

How do we want to proceed? Once the API shape is final I can open a heads-up issue in each affected repo linking the migration path, or is that better left to @BsAtHome as the API author? And if you maintain or use an external driver not on this list, please name it here.

[BsAtHome]

I searched GitHub for out-of-tree consumers of the C API. In ascending order of notoriety, these will need porting:

• wafaer/SoemMitionDevelop: SOEM-based EtherCAT motion

This one copies whole parts of LinuxCNC code and has stripped the copyright/GPL notices. This is clearly an infringing implementation that must be handled as such. The repo owner should be warned to reinstated the copyright notices and attributions.

• rene-dev/stm-hal: STM32F4 USB HAL component

Looking at the details, this code does not touch any LinuxCNC HAL constructs. This code is also stale and hasn't been touched in 14 years.

• tinkercnc/spi-fpga-driver: Mesa FPGA cards over RPi SPI (hm2_rpspi)

The code is stale (not touched in 10+ years). The RPi interface for hm2 has been superseded by the hm2_spix driver for quite some time. This code seems to deal with (ancient) Pluto cards. Not sure whether we should bother.

• ftkalcevic/hidcomp: USB HID input component

This one copies the hal.h into its own repo instead of using the include from a out include dir. It hasn't been touched for 7+ years, so I guess building with any recent LinuxCNC will fail on more than the HAL issue.

• ExcessiveOverkill/universal-IRC-1: 6-axis robot arm control

This one has copied the hal/ source-tree over (2.8 version). It is unclear why. But this robot should just run with some kinematics and components configured in .hal-files and a proper INI-file. For r2000_bias_torques.comp and r2000_joint_offsets.comp you could just use halcompile, no need to copy the HAL sources for that (still needs porting).

• jamwaffles/linuxcnc-hal-rs: Rust HAL bindings; wraps the C API, so every Rust component rides on this

This needs to be substantially rewritten. It exhibits the same problem as the old pyhal module and hal.hh.

• Expatria-Technologies/remora-flexi-hal: Flexi-HAL fork of Remora

These C-coded components need to be ported, just like we did with in-tree components. Should be straight forward (beware of the parameter gremlins).

• dbraun1981/hal-cia402: CiA402 drive state machine (.comp, probably a free rebuild)

Should be a straight forward component update and halcompile.

• scottalford75/Remora: STM32/RPi motion boards (NVEM, EC500, ...)

This one can also be updated quite straight forward and also has some parameter gremlins. However, at first glance, it has usage of float typed position, which is wrong. There are probably other things that should be checked in the components.

Smaller userspace pieces (VFDs, serial IO) are mostly Python and unaffected; any written in C join the list. Machinekit tracks its own HAL and is out of scope.

Python code is normally not affected. Unless it uses the wrong python interface (like pyhal, which we are going to kill real soon now).

How do we want to proceed? Once the API shape is final I can open a heads-up issue in each affected repo linking the migration path, or is that better left to @BsAtHome as the API author?

We can notify the repo owners for the newer stuff. But anything pre-2.9 is out of scope IMO.

There will be an addition to the 2.9 branch halcompile to make it mostly forward compatible with the 2.10 branch. At least there will support the X_set() method that is a requirement in 2.10. Also types will be added. The only problem for users is that 2.9 does not know about 64-bit, so you cannot use components that depend on it in a back-and-forth way.

And if you maintain or use an external driver not on this list, please name it here.

Yes, please let us know what is out there.