[Xenomai] Migrating from Xenomai to PREEMPT_RT

Asier Tamayo asier.tamayo at onaedm.com
Thu Aug 28 11:57:21 CEST 2014


Dear Philippe,

Thank you for your support.

> - moving to Yocto means changing the whole environment, unless you go
> for Denx's ELDK, which is Yocto-based _and_ Xenomai-enabled, in which
> case you would not have to port your application.
> 
Sadly, ELDK doesn't have x86 among its support architectures. Surely, they can add it, but at a cost.

> - moving to straight preempt-rt means changing your programming model
> from dual kernel to single kernel, porting your application from
> Xenomai's "native" API to POSIX, and porting your drivers to a single
> kernel system. A native incarnation of RTDM does exist, but we did not
> receive any feedback since it was released (many) years ago, so rough
> edges may exist.
> 
Which are the "philosophical" changes in changing my programming model from dual kernel to single kernel? Should I expect many problems in porting the native API to POSIX? Should I try another solution instead of using the native incarnation of RTDM in preempt-rt? Which one?

> - upgrading Elinos to Xenomai 2.6.x means updating your kernel - which
> is something you have to do for other reasons anyway - and building a
> drop in replacement of the Xenomai libraries and tools in user-space,
> for replacing the legacy ones shipped with Elinos. Kernel-wise, the
> requirement is to have an I-pipe patch available for your kernel version
> of choice. The upcoming Xenomai 2.6.4 supports kernel 3.14.
> 
If I'm not confused, applying the I-pipe patch to the ELinOS kernel would add the Xenomai support, but I'm not sure if the ELK tool (Embedded Linux Konfigurator) will show me that option. I'll ask Sysgo about this. While they answer, has anyone got any experience doing something similar?

> Mercury (i.e. single kernel Xenomai 3 configuration) would allow you to
> move to preempt-rt without having to switch APIs from Xenomai 2.x
> "native" to POSIX.
> 
Is the real-time performance (latency, jitter...) different in the single and in the double kernel approaches? If the performance depends on the RT approach (i.e., preempt-rt performance in the Mercury architecture and Xenomai v2 performance in the Cobalt one), are there any benchmarks comparisons between them? The ones I have found are quite outdated.

If I use the Mercury architecture, do I need to patch my ELinOS distribution (already with PREEMPT_RT patch) in any way? From the documentation, I assume I don't have to, but I need to be sure about this point.

Best regards,

Asier Tamayo 
 

> -----Mensaje original-----
> De: Philippe Gerum [mailto:rpm at xenomai.org]
> Enviado el: miércoles, 27 de agosto de 2014 13:15
> Para: Asier Tamayo; xenomai at xenomai.org
> Asunto: Re: [Xenomai] Migrating from Xenomai to PREEMPT_RT
> 
> On 08/27/2014 10:45 AM, Asier Tamayo wrote:
> 
> > Full story:
> > I have been using Xenomai for some time and must say I am really happy
> with the results (latencies, ease of programming, clear separation between
> the RT and non-RT parts...). My board is an Atom N270 based one, and runs
> a kernel 2.6.34 compiled with Sysgo's ELinOS 5.2 tool. I have mainly used
> the native skin, as well as some RTDM drivers.
> >
> > Now, I have to start using a new AMD G-Series T52R based board, and
> kernel 2.6.34 shows some problems with it. Therefore, I have to update the
> kernel to a newer one, but ELinOS has dropped the Xenomai support. As far
> as I can think, I now have three options: try to install Xenomai in ELinOS
> by myself, start using another tool or leave Xenomai and use the
> PREEMPT_RT patch. The first option may be very error prone (in fact, I
> have already updated once the Xenomai version in ELinOS, but the tool had
> Xenomai support integrated previously in it). The second solution would
> surely put me in the Yocto path, which I think can be the correct one, but
> the learning step might require too much time from me.
> >
> 
> Actually, updating your Elinos base to Xenomai 2.6.x would likely be
> much less error prone than any other option, although I agree that
> moving to Yocto is likely the best long term option.
> 
> Looking at the involved components:
> 
> - moving to Yocto means changing the whole environment, unless you go
> for Denx's ELDK, which is Yocto-based _and_ Xenomai-enabled, in which
> case you would not have to port your application.
> 
> - moving to straight preempt-rt means changing your programming model
> from dual kernel to single kernel, porting your application from
> Xenomai's "native" API to POSIX, and porting your drivers to a single
> kernel system. A native incarnation of RTDM does exist, but we did not
> receive any feedback since it was released (many) years ago, so rough
> edges may exist.
> 
> - upgrading Elinos to Xenomai 2.6.x means updating your kernel - which
> is something you have to do for other reasons anyway - and building a
> drop in replacement of the Xenomai libraries and tools in user-space,
> for replacing the legacy ones shipped with Elinos. Kernel-wise, the
> requirement is to have an I-pipe patch available for your kernel version
> of choice. The upcoming Xenomai 2.6.4 supports kernel 3.14.
> 
> > So, maybe the right solution would be to leave Xenomai and embrace the
> PREEMPT_RT patch, which is already supported by ELinOS. Has anyone got any
> experience with it? Which difficulties should I expect to find in the
> migration process? Any special problems with RTDM, shared memory...?
> >
> > Has anyone got information about latencies and performance comparison
> between Xenomai and PREEMPT_RT patch? I have found some in
> https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf, but would like to
> have as much as possible to make the choice.
> >
> > Is Xenomai 3 changing my situation in any way? Maybe using the Mercury
> architecture, in which I do not need to patch the kernel?
> 
> Mercury (i.e. single kernel Xenomai 3 configuration) would allow you to
> move to preempt-rt without having to switch APIs from Xenomai 2.x
> "native" to POSIX.
> 
> >
> > What do you think about the issue?
> >
> > [From Xenomai 3 FAQ - http://xenomai.org/introducing-xenomai-3/:
> >     Q: I can run POSIX based applications directly over a PREEMPT_RT
> kernel on my target system, so what is the point of running Xenomai 3?
> >     A: If your application is already fully POSIXish, and the
> performances requirements are met, then there is likely no point.(...)]
> >
> 
> This is fairly straightforward:
> 
> Xenomai 3 can either supplement the host kernel with a small co-kernel
> for delivering real-time performances (aka "Cobalt" configuration), or
> fully rely on the underlying kernel if it is deemed real-time already
> (aka "Mercury").
> 
> In the latter case, if preempt-rt is available on your hardware/kernel
> combo, meets your real-time performance requirements, then you do not
> need Xenomai 3 to write POSIX apps, since the glibc provides for this API.
> 
> However, if your app is not POSIXish but based on an API Xenomai
> emulates/implements, then you may want to use Xenomai 3 compared to
> converting this app to POSIX, which is quite often an error prone
> process. Xenomai 2.x "native" API is available with Xenomai 3, including
> for a single kernel configuration (e.g. preempt-rt).
> 
> --
> Philippe.




More information about the Xenomai mailing list