pluto_servo / pluto_step / pcl720: not built on uspace since 2014, docs links silently missing #4505
Description
While investigating missing links in the CI docs build (see #4471, components_gen.adoc lacks pcl720, pluto_servo, pluto_step), I found the root cause: these three driver comps have not been built on uspace since 2b0c9aa (June 2014), when the BUILD_SYS=uspace whitelist in src/hal/components/Submakefile was introduced with only serport (later also mesa_7i65, mesa_uart).
Since every modern install (preempt-rt) is a uspace build, these drivers are effectively unavailable to all current users. Only an RTAI/kbuild build produces them. Their man pages are also absent from the published docs (linuxcnc.org returns 404 for pluto_servo.9.html and pcl720.9.html), so the entries in components.adoc point to nothing.
The situation differs per driver:
- pluto_servo / pluto_step: no technical blocker.
pluto_common.hhas had a userspace I/O path (sys/io.h) since 2007, the comp compiles cleanly with uspace flags, and its dependencyhal_parportbuilds on uspace. It was simply never whitelisted and never hardware-tested on uspace. - pcl720: genuinely kernel-only. It includes
<asm/io.h>unconditionally and uses kernel types, so a uspace build needs an actual port.
Questions for direction:
- pluto_servo/pluto_step: whitelist for uspace (compile-tested, needs someone with Pluto-P hardware to verify), or leave as-is?
- pcl720: worth a port, or formally deprecate?
- Independently: should the docs note that these drivers are only available on kbuild/RTAI builds? Right now the docs present them as normal components.
Side note: make clean-manpages only removes $(GENERATED_MANPAGES), which on uspace excludes these drivers' man pages, so stale pluto_servo.9 etc. survive forever in old build trees and confuse the generated component list (that is why a local Trixie build showed links the CI build did not).
Activity
BsAtHome commentedon Sep 7, 2026
There are several more rtai/kernel only drivers. The question is who is using them.
List found when doing the getter/setter conversion:
grandixximo commentedon Sep 7, 2026
Yes, all kbuild-only, and kbuild today means RTAI: configure only supports uspace or an RTAI install path, so every driver on your list requires an RTAI kernel build.
The Makefile block (
ifneq ($(BUILD_SYS),uspace)in src/Makefile) gates two more:hal_evoreg(Siemens EVOREG motion control board, 2003)hal_skeleton, which is not real hardware but John Kasunich's template for new drivers. I'd exclude it from any poll and simply stop building/installing it.Everything on the list is ~2000-2005 era ISA/PCI/parport cards (Servo-to-Go, Motenc, VTI, EVOREG, AX5214H, Opto22 AC5, pci_8255, PCL720, Pluto-P). None have userspace ports, and porting means working against hardware nobody can test.
On finding out who uses them: agree, ask the users first. I'd post the actual hardware names (not file names) on the forum and the users mailing list: "still running any of these on RTAI?" Whatever gets zero response gets a deprecation note in docs + release notes for one cycle, then removal.
One exception worth carving out: pluto_servo/pluto_step compile cleanly on uspace as-is (pluto_common.h has had a userspace I/O path since 2007, hal_parport builds on uspace). If a Pluto-P user shows up in the poll, whitelisting plus a hardware test is all it takes. The rest are real porting efforts.
rene-dev commentedon Sep 13, 2026
rtai is 64 bit only. I doubt that any pc running this hardware is capable of 64 bit.
andypugh commentedon Sep 13, 2026
I wrote PCL720 on a whim based on a single user on the forum. He has confirmed that it is no longer in use.
Time well spent, though; he has been a forum stalwart ever since.