History of RealtimeConfiguratonProposal

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Difference (from prior major revision) (minor diff)

Changed: 43c43,45

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

The configuration options have been changed as

(for now, this only applies to http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/integration-configuration-dev as it is not merged yet):

Changed: 47c49

--with-threads= one of:

--with-threads=<arg>, arg being one of:

Changed: 51c53

* rt-preempt as above, but hardened rtapi_app.

* rt-preempt-user as above, but hardened rtapi_app.

Changed: 53c55

* rt-preempt-kthreads: this would imply: an rt-preempt kernel, kthreads for RTAPI execution, and .ko modules.

* rt-preempt-kernel: this would imply: an rt-preempt kernel, kthreads for RTAPI execution, and .ko modules.

Changed: 61,62c63,86

These options will result in the following config.h defines, shell and
makefile variables:

Build system: there are two styles, 'kbuild' (kernel modules) and 'user-dso' (userland shared objects). The thread style implies a build system: posix, xenomai-user, rt-preempt-user imply 'user-dso', the others imply 'kbuild'.

Building hardware drivers can be controlled with --enable-drivers. It is default 'yes' except for --with-threads=posix. Some hardware drivers will build as kernel modules only, some as user shared objects, some may build as both; in that case the Submakefile needs to test for BUILD_SYS having the proper value.

The cpp symbols 'SIM', 'SIMULATOR', and 'RTAPI_SIM' have been removed as they do not make sense any more. A simulator configuration is '--with-threads=posix', which is now implied by --enable-simulator.

The shell/Makefile? variables are:

THREADS= one of: posix, rt-preempt-user,rt-preempt-kernel, xenomai-user, xenomai-kernel, rtai

BUILD_DRIVERS=yes or no

BUILD_SYSTEM=kbuild or user-dso

THREADS is reflected in config.h as one of the following defined:

RTAPI_POSIX

RTAPI_RT_PREEMPT_USER

RTAPI_RT_PREEMPT_KERNEL

RTAPI_XENOMAI_USER

Changed: 64,65c88

'SIM' will be removed as it doesnt make sense any more, and replaced
by a combination of:

RTAPI_XENOMAI_KERNEL

Changed: 67,73c90

RTAPI_THREADS = one of :
RTAI_KERNEL
XENOMAI_KERNEL
XENOMAI_USER
RT_PREEMPT_USER
RT_PREEMPT_KTHREADS
POSIX

RTAPI_RTAI

Removed: 75,77d91

MODULE_TYPE = one of:
KERNEL_MODULE
USER_DSO

Removed: 79d92

hence, the currently relevant configurations will define:

Changed: 81c94

SIM: RTAPI_THREADS=POSIX and MODULE_TYPE=USER_DSO

BUILD_DRIVERS is conditionally defined in config.h too.

Removed: 83d95

RTAI: RTAPI_THREADS=RTAI_KERNEL and MODULE_TYPE=KERNEL_MODULE

Changed: 85c97

For HAL, the RTAPI and ULAPI defines remain in their current form, and mean:

BUILD_SYSTEM is reflected in config.h as either

Changed: 87,93c99

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.

BUILD_SYSTEM_KBUILD or

Changed: 95c101

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:

BUILD_SYSTEM_USER_DSO defined.

Changed: 97,102c103

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

hal_parport

Added: 103a105

The experimental usermode parport driver from master: src/hal/simdrivers has been integrated into the main hal_parport.c/.h code using conditionals from above.

Changed: 105c107

A 'sudo make setuid' step after build will be required except if the configuration does not a) insert kernel modules b) does not do any direct IO for which elevated permissions are required.

Make setuid:

Changed: 107c109

---

this has been adapted to take care of the case 'threads=posix and drivers enabled', which requires rtapi_app to be setuid root.

Removed: 109d110

I look forward to comments.

Removed: 111,112d111

Barring better proposals forthcoming, I will work with
the folks working on the rt-preempt and xenomai integration branches to implement this scheme.

Published under a Creative Commons License

	Revision 6 . . (edit) October 27, 2012 3:07 pm by MichaelHaberler
	Revision 5 . . (edit) October 27, 2012 3:03 pm by MichaelHaberler
	Revision 4 . . October 25, 2012 6:27 pm by MichaelHaberler *[describe changes in integration-configuration branch]**
	Revision 3 . . (edit) October 18, 2012 2:57 pm by MichaelHaberler
	Revision 2 . . (edit) October 16, 2012 7:53 pm by MichaelHaberler
	Revision 1 . . October 16, 2012 7:44 pm by MichaelHaberler *[describe future RTAPI configure options]**