On 9/8/26 6:17 PM, Bertho Stultiens wrote:
On 9/8/26 11:03 AM, andy pugh wrote:
Is this discussion based on an expectation of withdrawing RTAI
support? My impression from scanning PRs has been that RTAPI support
has been expanding, with improved support for RTAI and also for
Xenomai.
Retiring RTAI would be a LinuxCNC 3.0 thing. A lot of bitrotted code
has been fixed and Xenomai got fixed too. As long as the code is
there, it must be maintained.
The driver problem is that some of these cards are ISA and I have a
hard time believing that anyone would buy a fortune swallowing modern
industrial PC to get an old card working with a /new/ LinuxCNC. Even
with the PCI cards you'd have a very hard case these days.
If you use an old PC, then you may run into the problem of memory and
speed with any modern software. So you are still limited to older
versions/distros/kernels.
Nobody would build a new system like that today. Only (desperate)
repairs of old systems that cannot be upgraded right away would ever
reuse the old stuff.
If you ever upgrade these old systems, then you'd buy a newer more
capable PC/SBC and IO board with full support. And that would fill
less space and be cheaper to boot.
Agreed: retiring RTAI is a 3.0 decision, and until then the code stays
maintained.
On Andy's point about RTAPI support expanding: that expansion is real
but it is uspace work. Xenomai (posix skin and EVL) lives entirely in
uspace_xenomai*.cc, no kbuild pass, no kernel modules, and the kernel
patch side is upstream's burden, not ours. RTAI kernel mode is the only
path that requires kernel module builds and these ten drivers.
Deprecating RTAI does not touch any of the growing parts.
So why not sequence it as: mark these drivers deprecated in the 2.10
docs and release notes, removal slated for 3.0; if a user with upgrade
intent appears for a specific card during the cycle, that card gets
ported (pluto first, it compiles on uspace today); at 3.0 the drivers go
with RTAI. The deprecation notice doubles as the poll, reaching more
users than any single list post. Repairs of old systems stay on old
distros, as you said, so master removal strands nobody.
The drivers could carry this deprecation independently of a project-wide
RTAI decision. It is a docs-level change, and if RTAI survives into 3.0
the list can be re-evaluated then.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
