pluto_servo / pluto_step / pcl720: not built on uspace since 2014, docs links silently missing

[grandixximo]

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.h has had a userspace I/O path (sys/io.h) since 2007, the comp compiles cleanly with uspace flags, and its dependency hal_parport builds 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:

1. pluto_servo/pluto_step: whitelist for uspace (compile-tested, needs someone with Pluto-P hardware to verify), or leave as-is?
2. pcl720: worth a port, or formally deprecate?
3. 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).

[BsAtHome]

There are several more rtai/kernel only drivers. The question is who is using them.

List found when doing the getter/setter conversion:

• hal/drivers/hal_ax5214h.c
• hal/drivers/hal_motenc.c
• hal/drivers/hal_stg.c
• hal/drivers/hal_tiro.c
• hal/drivers/hal_vti.c
• hal/drivers/opto_ac5.c
• hal/drivers/pci_8255.c
• hal/drivers/pcl720.comp
• hal/drivers/pluto_servo.comp
• hal/drivers/pluto_step.comp

[grandixximo]

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.