[Home]RealtimeConfiguratonProposal

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Showing revision 1

Adapting LinuxCNC configure to multiple realtime environments

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.

Therefore, I propose to change the configuration namespace as follows:

--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


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions | View current revision
Edited October 16, 2012 12:44 pm by MichaelHaberler (diff)
Search:
Published under a Creative Commons License