Re: [Xenomai-help] General Xenomai / RTAI Skin Usage Questions

[Philippe Gerum <rpm@xenomai.org>]

andreas.spieker@domain.hid wrote:
> Hello,
> 
> I have an existing user-space Application,
> programmed as a multithreaded C Program,
> until now relying on RTAI3.2, mostly on time + task services,
> basically to let all the threads run periodically,
> for IPC Stuff  I use SystemV-IPC (!).
> 
> After the Split between RTAI and Xenomai I'm looking
> for an alternative to RTAI, because since Kernel 2.6.10,
> I was not longer able to get RTAI running (Kernel freezes)
> and the Mailing List Members were not really willing to give me
> some hints or a "functioning" kernel config file.
> 
> So my questions are:
> 1.)  Do you think Xenomai (with RTAI Skin ?) is the right way for me to go?

Note: As a consequence of the split, the once dubbed "rtai" or "native" skin 
available with RTAI/fusion has been strictly renamed Xenomai's "native" skin. 
The legacy RTAI compatibility skin for apps in kernel space available as the 
"compat" skin with RTAI/fusion has been renamed Xenomai's "rtai" skin.

Xenomai's native skin focuses on compactness, consistency and orthogonality; I'm 
not the right one to ask if this goal has been achieved, but at least, I'm not 
receiving hate mail for this stuff, so this should be mostly ok. The doc is 
available on-line:  http://download.gna.org/xenomai/documentation/html/api/

You could also use the POSIX skin, which is also fully available to user-space 
apps. The idea of this skin is to provide a seamless and deterministic 
replacement for a set of POSIX services applications can use. As a matter of 
fact, applications only using this subset can be linked with no change against 
the Xenomai libpthread_rt library, or the regular LinuxThreads/NPTL libraries.
The list of POSIX services which have been "shadowed" this way is available in 
skins/posix/lib/posix.wrappers. Service calls that do not appear in this list 
are simply redirected to and processed by the underlying LinuxThreads/NPTL 
layer. The difference between a shadowed call and a regular one is of course 
determinism: the former will be processed by the Xenomai subsystem, the latter 
by the Linux kernel.

If you want an API that resembles traditional RTOS interfaces, then the native 
skin is likely the best choice. If you prefer going for the 1003.1x standards, 
the the POSIX skin is best. Xenomai is API agnostic anyway, use the one that 
fits your needs, all are equally maintained.

> 2.)  Is there a simple (LXRT-like) demo with makefile for RTAI-Skin usage?

There are snippets which sketch the use of the native skin: look at 
skins/native/snippets. There is also a rather detailed tech. article about using 
it: http://download.gna.org/xenomai/documentation/pdf/Native-API-Tour.pdf

> 3.)  Actually, AFTER having created my threads, I use rt_task_init() +
>  rt_task_make_periodic() + rt_task_wait_period() in these threads to
> get them running periodically. So I turn an existing thread into something
> with soft-realtime capabilities, the API calls refer to the already running
> thread. .
> When using Xenomai, do I have to change to rt_task_create() +
> rt_task_start(),
> therefore creating my threads from the xenomai api?

No, the corresponding call is rt_task_shadow() for the native API, or invoking 
pthread_setschedparam(pthread_self(),SCHED_FIFO,&schedparam) with the POSIX skin.

> I fear this would bring a lot of changes to my existing program, is this
> right and is this
> unavoidable?
> 4.) Is there a documentation which options must be set or unset in the
> linux kernel .config to get
> xenomai running? I had some problems, but was able to get them solved using
> an old
> "functioning" kernel config file (in contrast to RTAI).
> 

Unfortunately, there is no cookbook for this purpose, yet. This said, here are a 
few guidelines:

- Only use _vanilla_ Adeos patches, either obtained from there:
http://download.gna.org/adeos/patches/v2.6/adeos/, or contained in the Xenomai 
distros.

- A kernel option that causes Xenomai (or Adeos) to blatantly malfunction or 
even crash is a freaking BUG, and should be reported asap to the Xenomai-core 
list or the Adeos-main list. IOW, there is no such thing as options allowed to 
crash your box with Adeos/Xenomai because of some "don't care attitude"; would 
such bug happen, it must and will be fixed. All the people involved in 
contributing to both projects try to make sure that any option could be enabled 
without risking terminal damage to anyone's setup. The worst thing that should 
be allowed to happen is high latency spots, because some options might cause 
some hardware to interact badly with critical resources Adeos/Xenomai also 
happen manage.

- Usual suspects for high (in the pathological sense) latency spots due to 
particular kernel configuration are (from the top of my head):
	+ APM
	+ possibly ACPI depending on what hw is controlled (Like Emacs I'm using, ACPI 
seems to handle everything but the kitchen sink, so some configs with ACPI on 
may work, others might not)
	+ CPU frequency scaling (cpufreq stuff, of course)
	+ some DMA supports may cause bus mastering artefacts delaying interrupt 
service but again, a lot don't.

There are even some interesting cases where you actually need some options to be 
on for the latencies to go down. Read the TROUBLESHOOTING file in Xenomai's top 
level dir, it's usually helpful.

- Other sources of increased latency, but less pathological usually comes from
the Kernel hacking section: CONFIG_FRAME_POINTER for x86, CONFIG_DEBUG_SPINLOCK, 
CONFIG_DEBUG_SPINLOCK_SLEEP are known to add some overhead, but the increase is 
still bareable compared to the valuable debugging information those options 
bring in if needed. In any case, Xenomai/Adeos developers actually always turn 
those options on to make sure that the real-time side always plays well with the 
Linux kernel. IOW, production systems should have those off, but development 
setups may want them on.

- On x86, APIC is _good_ for you when you have one on your CPU, Xenomai plays 
nicely with it, and the overall latency is significantly reduced, especially in 
oneshot mode.

> Thanks for any hints and comments,
> Andreas Spieker
> 
> PS: *** I will be in holidays the next weeks, so will notbe able to reply
> immediately to postings ***
> 
> 
> -----------------------------------------------------
> Dr.-Ing. Andreas Spieker
> Research Information and Communication
> Assisting Systems (REI/AA)
> 
> DaimlerChrysler AG
> HPC 050-G023
> D-71059 Sindelfingen
> Telefon: +49 7031 4389 774
> Telefax:  +49 7031 4389 264
> Mobil:     (+49) (0)179 -10 84 718
> email: andreas.spieker@domain.hid
> 
> Besucheradresse:
> DaimlerChrysler AG
> REI/AA, Zimmer 1.103
> Hanns-Klemm-Straße 45
> 71034 Böblingen,
> -----------------------------------------------------
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.