The current configuration options for LinuxCNC regarding 'real time environments are:
I believe the underlying assumptions at the time were:
Several options for realtime Linux have appeared since, which are:
These two platforms provide new options:
Also, given reasonable latency of one of the user RT process schemes, it becomes entirely feasible to use user-mode device drivers.
It should be obvious that these new options cannot be consistently adressed with the current configuration assumptions. Realtime does not imply kernel threads exclusively anymore, and User process mode does not imply 'useless so no drivers' please. Also, I am unsure what help the concept of a 'realtime signature' will provide.
As work progresses on different branches in parallel, configuration problems will likely be solved ad-hoc (ad-hack?) and conflicts will arise during merge, also with the consequence of an even more incoherent set of options.
--with-realtime will be deprecated in its current form, and replaced
by:
--with-threads= one of:
These options will result in the following config.h defines, shell and makefile variables:
'SIM' will be removed as it doesnt make sense any more, and replaced by a combination of:
RTAPI_THREADS = one of : RTAI_KERNEL XENOMAI_KERNEL XENOMAI_USER RT_PREEMPT_USER RT_PREEMPT_KTHREADS POSIX
MODULE_TYPE = one of: KERNEL_MODULE USER_DSO
hence, the currently relevant configurations will define:
SIM: RTAPI_THREADS=POSIX and MODULE_TYPE=USER_DSO
RTAI: RTAPI_THREADS=RTAI_KERNEL and MODULE_TYPE=KERNEL_MODULE
For HAL, the RTAPI and ULAPI defines remain in their current form, and mean:
from hal.h (no change expected): HAL uses the RTAPI/ULAPI interface. If RTAPI is #defined, (done
by the makefile) hal_lib.c would generate a kernel module hal_lib.o that is insmoded and provides the functions for all kernel module based components. The same source file compiled with the ULAPI #define would make a user space hal_lib.o that is staticlly linked to user space code to make user space executables.
For RTAPI, it is a bit unclear whether the old assumption will suffice to cover all of the above cases; if not, one of the abovementioned defines should be used to resolve the issue:
..'rtapi.h', defines the RTAPI for both realtime and
non-realtime code. This is a change from Rev 2, where the non- realtime (user space) API was defined in ulapi.h and used different function names. The symbols RTAPI and ULAPI are used to determine which mode is being compiled, RTAPI for realtime and ULAPI for non-realtime.
---
I look forward to comments.
Barring better proposals forthcoming, I will work with the folks working on the rt-preempt and xenomai integration branches to implement this scheme.
Michael Haberler