User space RTAI syscalls have 16 extensions slots. They allow any user to
extend RTAI with her/his own user space callable APIs without touching
RTAI itself. For the most efficient inline usage of any extension user slots 
must be assigned statically. RTAI itself uses a few extension slots for some
of its native addons, as listed below.

Those already used by modules found in this distributions are:
0  - RTAI itself (hardwired),
1  - tasklets    (hardwired),
2  - watchdog    (hardwired),
9  - comedi,
10 - fifos,
14 - serial,
15 - rtdm.

So you can reuse the above slots only if you are not using the related modules
found in this distribution. In any case check the value returned by: 
set_rt_fun_ext_index.

N.B. "(hardwired)" above means they are assumed as basic RTAI proper extensions.
Nonetheless extension 1 and 2 do check if they can install into their hardwired 
slots, exiting their installation in error if they cannot. 
So you can make the related slot yours if neither tasklets nor watchdog are 
being used by your applications; __NEVER__ USE 0 though. 
In any case you'd better choose the other many free slots available to avoid
any trouble.

If in doubt about slots engaged already use something like the following piece
of code in your extension module to discover them:

#define MAX_LXRT_EXT 16
do {
	int i;
	struct rt_fun_entry fun;
	for (i = 0; i < MAX_LXRT_EXT; i++) {
		if (set_rt_fun_ext_index(&fun, i) < 0) {
			rt_printk("< LXRT SLOT %d ENGAGED >\n", i);
		} else {
			reset_rt_fun_ext_index(&fun, i);
		}
	}
} while (0);

It has been already said above but, if you are still asking yourself why there 
is a forced staticalisation of LXRT extension slots assignement, while it 
would be trivial to have functions to get/free slots dynamically, think about 
efficiency first, especially if direct (eager in the related RTAI config 
caption) inlining is used.

WARNING

If you intend to use Linux i386 with REGPARM configured notice that all your
functions callable from user space must be prefixed with "RTAI_SYSCALL_MODE".
In such a way they will be usable both with and without REGPARM. If you do
not do so then avoid configuring REGPARM for Linux, which is not possible from
2.6.20 onward, where REGPARM is the only way to operate and so it is nomore
an option.
