# Survey & HOWTO Real-Time

## lalebarde

SURVEY of REAL-TIME technologies available on Linux

Thread table of Content :2009-08-29 p. 1 : SURVEY of REAL-TIME technologies available on Linux

2009-08-30 p. 1 : HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - Step 1 : getting the sources patched

2009-08-30 p. 1 : HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - Step 2 : building the kernel

2009-08-31 p. 1 : HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - Step 3 : Testing

----------

## lalebarde

It seems that gentoo-sources were used : HOWTO_Xenomai_2.1.x_Branch : http://www.gentoo-wiki.info/HOWTO_Xenomai_2.1.x_Branch

I am going to try to start from that.

----------

## lalebarde

I progress and I am going to write a HOWTO.....

HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - Step 1

References :(1) http://www.gentoo-wiki.info/HOWTO_Xenomai_2.1.x_Branch

(2.1) http://www.xenomai.org

(2.2) http://www.xenomai.org/index.php/Xenomai_quick_build_quide

(2.3) http://www.xenomai.org/index.php/FAQs

(2.4) http://download.gna.org/xenomai/stable/

(3.1) http://dev.gentoo.org/~dsd/genpatches/kernels.htm

(3.2) http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

(3.3) http://en.gentoo-wiki.com/wiki/Writing_Ebuilds

Introduction :

I am not a Gentoo expert, just a 3 years experience "newbie". So Ref. (1) has been my bible for this work, and I have sticked to its philosophy. Besides, lot of adaptations and retrofit were needed to get the sources emerged properly. I explain the rationals in this tuto of the issues encountered in order that everyone can adapt as easily as possible to its particular situation.

First step : getting the sources patched

From  *Ref. (2.3) wrote:*   

> you may use any I-pipe patch for any kernel version ranging from 2.4.35/i386 to 2.6.29.4/x86.

 

Moreover, as Ref. (1) built xenomai 2.1.3 with gentoo sources 2.6.17-r1, I conclude or make the reasonnable guess that you can build any xenomai version on any linux kernel, either gentoo-sources, vanilla, or other. As a first consequence, you can start from the kernel you do use and which you have had tuned and works perfect. Philosophycally, It is appealing in the sence of reducing considerably the potential of issues. That said, my recommandation is to use xenomai sources posterior but not too much from your kernel version, with regard to date of availability. As a general remark, we should be able to mix different patches e.g. harden+tuxonice+gentoo+xenomai   :Razz: .

Put in your own overlay a copy of your kernel sources ebuild. Ref. (3.2) & (3.3) are your friends.

Identify your xenomai version in Ref. (2.4)

I suggest that you rename your ebuild directory and your ebuild file like this : 

/usr/portage/local/mesEbuilds/sys-kernel/xenomai-sources-2.4.9-gentoo-sources/xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5.ebuild

What is important is that the version number before ".ebuild" has to be the one of your kernel sources, since the ebuild uses the command detect_version. This command is used to calculate the environment variable used to build the fetch path for kernel sources. I don't understand why it is not documented in Ref. (3.2) nor (3.3) ?

Then merge this ebuild with the one in Ref. (1) or mine - since I made corrections as depicted below. Here is my xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5.ebuild :

```
# Copyright 1999-2009 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header:

# /usr/portage/local/mesEbuilds/sys-kernel/xenomai-sources-2.4.9.ebuild,v 0.1 2009/08/29 16:50:04 $

ETYPE="sources"

K_WANT_GENPATCHES="base extras"

K_GENPATCHES_VER="8" # used by gentoo-sources-2.6.28-r5 : genpatches-2.6.28-8.base.tar.bz2 & genpatches-2.6.28-8.extras.tar.bz2

inherit kernel-2 eutils

detect_version

detect_arch

# Xenomai 2.4.9

XENO_VER_MAJOR="2"

XENO_VER_MINOR="4"

XENO_REV_LEVEL="9"

XENO_VER_STRING="${XENO_VER_MAJOR}.${XENO_VER_MINOR}.${XENO_REV_LEVEL}"

XENO_SRC="xenomai-${XENO_VER_STRING}"

XENO_TAR="${XENO_SRC}.tar.bz2"

XENO_URI="http://download.gna.org/xenomai/stable/${XENO_TAR}"

KEYWORDS="x86"

IUSE=""

HOMEPAGE="http://www.xenomai.org/ http://dev.gentoo.org/~dsd/genpatches/ http://www.gentoo-wiki.info/HOWTO_Xenomai_2.1.x_Branch"

DESCRIPTION="Full sources including the Gentoo patchset for the ${KV_MAJOR}.${KV_MINOR} kernel tree on top of Xenomai nanokernel ${XENO_URI}"

SRC_URI="${KERNEL_URI} ${GENPATCHES_URI} ${ARCH_URI} ${XENO_URI}"

src_unpack() {

   kernel-2_src_unpack

   # Portage's ``unpack'' macro unpacks to the current directory.

   # Unpack to the work directory.  Afterwards, ``work'' contains:

   #   linux-2.6.29-xenomai-r5

   #   xenomai-2.4.9

   cd ${WORKDIR}

   unpack ${XENO_TAR} || die "unpack failed"

   cd ${WORKDIR}/${XENO_SRC}

   epatch ${FILESDIR}/prepare-kernel.patch || die "patch failed"

   scripts/prepare-kernel.sh --linux=${S} || die "prepare kernel failed"

}

pkg_postinst() {

   kernel-2_pkg_postinst

   einfo "For more info on this patchset, and how to report problems, see:"

   einfo "${HOMEPAGE}"

   elog "As you may have adapt this ebuild to match your kernel version, copy your .config before going on with making the kernel"

}
```

I made some corrections on the one in Ref. (1) in order it works - I assumed this is due to portage upgrades but I don't know - my first attempts sticking to Ref. (1) failed :

In 

```
scripts/prepare-kernel.sh --linux=${S} <<EOF || die "prepare kernel failed"

EOF
```

I have had to suppress the EOF story. If someone can explain, one is welcome.

You have to customize the following :

K_GENPATCHES_VER="8"  If you have kept your kernel, this is unchanged, otherwise, cf Ref. (3.1) to match the patch with your kernel version.

XENO_VER_MAJOR="2"   These three variable follows the xenomai version you have chosen cf. Ref (2.4)

XENO_VER_MINOR="4"

XENO_REV_LEVEL="9"

Take care that all arch are not supported. Visit Ref. (2.1) to check "x86" and "x86_64" are ok. I don't remember the precise link.

As you can see, there is this line : 

```
epatch ${FILESDIR}/prepare-kernel.patch
```

 explained in Ref (1). So, we have to build the prepare-kernel.patch file and put it in our overlay in the file directory - after having mkdir it of course. A model of this file is given in Ref. (1). This patch shall change :

```
ln -sf $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f
```

 by : 

```
cp $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f
```

The way that has worked for me is :wget the xenomai tarball in a tmp directory

Get the xenomai-2.4.9/scripts/prepare-kernel.sh from the tarball (the version number may change)

Make a copy

Modify the copy as required

Make a diff between the two to build the patch : 

```
diff -C 3 prepare-kernel.sh.From.TarBall prepare-kernel.sh.Upgraded > /usr/portage/local/mesEbuilds/sys-kernel/xenomai-sources-2.4.9-gentoo-sources/files/prepare-kernel.patch
```

 "/usr/portage/local/mesEbuilds" being your own overlay path. "/usr/portage/local/mesEbuilds/sys-kernel/xenomai-sources-2.4.9-gentoo-sources/" is where you put your ebuild.

Here is my prepare-kernel.patch :

```
*** xenomai-2.4.9/scripts/prepare-kernel.sh   2009-05-21 16:34:54.000000000 +0200

--- xenomai-2.4.9/scripts/prepare-kernel.sh   2009-08-30 01:38:51.000000000 +0200

***************

*** 116,122 ****

                  if test x$forcelink = x1 -o \

           ! $xenomai_root/$target_dir/$f -ef $linux_tree/$link_dir/$f;

        then

!                     ln -sf $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f

                  fi

              else

                  if test `check_filter $link_dir/$f` = "ok"; then

--- 116,122 ----

                  if test x$forcelink = x1 -o \

           ! $xenomai_root/$target_dir/$f -ef $linux_tree/$link_dir/$f;

        then

!           cp $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f

                  fi

              else

                  if test `check_filter $link_dir/$f` = "ok"; then
```

It is of major importance in the first lines to set the path of the files from/to from the portage work directory : ${WORKDIR}/${XENO_SRC} - cf the ebuild.

Here we are, now build the manifest and emerge :

```
# ebuild xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5.ebuild manifest

# emerge -v xenomai-sources-2.4.9-gentoo-sources

```

An appreciate the result :

```
# eselect kernel list

Available kernel symlink targets:

  [1]   linux-2.6.16-rt29

  [2]   linux-2.6.24-gentoo-r8

  [3]   linux-2.6.25-gentoo-r7

  [4]   linux-2.6.27-gentoo-r8

  [5]   linux-2.6.28-gentoo-r5 *

  [6]   linux-2.6.28-xenomai-r5
```

Next step, we will build this new kernel.....Last edited by lalebarde on Sun Sep 06, 2009 8:56 am; edited 1 time in total

----------

## lalebarde

HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - step 2

Additional references :(2.5) https://mail.gna.org/public/xenomm-commits/2006-10/msg00012.html

(2.6) http://docs.huihoo.com/xenomai/Introduction-to-UVMs-rev-B.pdf

(2.7) http://osdir.com/ml/linux.real-time.xenomai.users/2006-02/msg00104.html

(3.4) http://www.gentoo.org/doc/en/kernel-upgrade.xml

Second step : building the kernel

Select your new kernel (adapt to your case) :

```
# eselect kernel set 6
```

Go there, copy your .config from the kernel you derived the xenomai one :

```
# cd /usr/src/linux

# cp -a ../linux-2.6.28-gentoo-r5/.config .
```

Config your new kernel, a new Real-time sub-system sub-menu has appeared, remove APM, CPU frequency scaling and ACPI has requested in the config menu, save and build : 

```
# make menuconfig

# make && make modules_install
```

Put this new kernel in /boot and update your boot loader as usual - cf Ref. (3.4). 

Now, we are going to emerge the xenomai system libraries. That requires another ebuild. We are going once again to follow Ref. (1).

Make the directory tree for this new ebuild in your overlay :

```
# mkdir -p sys-libs/xenomai
```

Put there the following ebuild : xenomai-2.4.9.ebuild

```
# Copyright 1999-2009 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /usr/portage/local/mesEbuilds/sys-libs/xenomai/xenomai-2.4.9.ebuild,v # 1.4 2009/08/30 22:44:15 $

inherit eutils linux-info

DESCRIPTION="Pervasive, interface-agnostic, hard real-time support"

HOMEPAGE="https://gna.org/projects/xenomai/"

LICENSE="LGPL"

SLOT="0"

SRC_URI="http://download.gna.org/xenomai/stable/${P}.tar.bz2"

IUSE="uvm debug smp x86-sep x86-tsc"

KEYWORDS="x86"

#DEPEND=">=xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5"

# On purpose, this ebuild does not use econf, emake or einstall.  The

# good reason: these specify --prefix=/usr without any way to

# override.  However, this ebuild allows Xenomai to apply its default

# prefix of /usr/xenomai.  Therefore it compiles and installs using the

# usual sequence of

#

#   ./configure

#   make

#   make DESTDIR=image install

src_compile() {

   # Xenomai's configuration step uses the kernel sources to build

   # modules.  Configuration also uses kernel sources for extracting

   # GCC architecture-specific flags.  However, this latter usage

   # *sometimes* breaks out of the Gentoo Portage sandbox!  Use

   # addpredict to mask the violation.

   addpredict ${KERNEL_DIR}/display_archflags.gcda

   # Also add the ``canonical'' kernel directory in case the directory is

   # actually a symlink as is usually the case with /usr/src/linux!

   addpredict `readlink -f ${KERNEL_DIR}`/display_archflags.gcda

   # To override the default system UVM heap size (128Kb) add the

   # following line

   #   XENO_OPT_SYS_HEAPSZ="256"

   # to your /etc/make.conf adjusting the Kb size to suit your needs.

   local myconf=""

   if [ -n "${XENO_OPT_SYS_HEAPSZ}" ]

   then myconf="${myconf} --enable-uvm-heapsz=${XENO_OPT_SYS_HEAPSZ}"

   fi

   # Pass the Linux kernel directory.  Do not let the configure

   # script guess; it might guess incorrectly if, for example, the

   # build and target hosts do no run the same kernel.  Passing

   # KERNEL_DIR lets you override if necessary by setting

   # KERNEL_DIR=some-kernel-source-path in a prefix to emerge!

   ./configure --with-linux-dir=${KERNEL_DIR} \

      $(use_enable uvm) \

      $(use_enable debug) \

      $(use_enable smp) \

      $(use_enable x86-sep) \

      $(use_enable x86-tsc) \

      ${myconf} || die "configure failed"

   make || die "make failed"

}

src_install() {

   make DESTDIR=${D} install || die "make install failed"

   dodir /etc/env.d

   >>${D}/etc/env.d/00xenomai echo "ROOTPATH=/usr/xenomai/bin"

   >>${D}/etc/env.d/00xenomai echo "PATH=/usr/xenomai/bin"

   >>${D}/etc/env.d/00xenomai echo "LDPATH=/usr/xenomai/lib"

   >>${D}/etc/env.d/00xenomai echo "MANPATH=/usr/xenomai/man"

   xeno_cflags="`${D}/usr/xenomai/bin/xeno-config --xeno-cflags`"

   xeno_ldflags="`${D}/usr/xenomai/bin/xeno-config --xeno-ldflags`"

   pkgconfigdir=/usr/lib/pkgconfig

   insinto ${pkgconfigdir}

   doins ${FILESDIR}/${PN}-native.pc

   dosed "s:@PV@:${PV}:g" ${pkgconfigdir}/${PN}-native.pc

   dosed "s:@xeno_cflags@:${xeno_cflags}:g" ${pkgconfigdir}/${PN}-native.pc

   dosed "s:@xeno_ldflags@:${xeno_ldflags}:g" ${pkgconfigdir}/${PN}-native.pc

}
```

It is the same as in Ref (1), except for : 

```
LICENSE="LGPL"

SLOT="0"

#DEPEND=">=xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5"
```

I suppressed the DEPEND because when I built the manifest with it, I got a "DEPEND: >=xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5 kernel_linux? ( virtual/linux-sources ), invalid atom: '>=xenomai-sources-2.4.9-gentoo-sources-2.6.28-r5'". I assume that having two versions numbers in the ebuild name of the kernel sources was not a good idea.

Build the manifest and emerge with defining the KERNEL_DIR variable to point on your gentoo-xenomai-kernel. Available USE flags are listed in Ref. (2.5), refer also to the README.INSTALL in the xenomai tarball, and to ref. (2.6) and (2.7) for UVM (User's space Virtual Machine). As explained by the xenomai team, coherence between options to build xenomai, and thereof the USE flags to select, with how the kernel is configured is of major importance :

 *README.INSTALL in the xenomai tarball wrote:*   

> Because of the strong decoupling between the kernel and user-space build procedures, Xenomai needs to make sure that all user-space options selected at configuration time will be consistent with the actual support the runtime libraries will get from the target kernel. For instance, enabling TSC support in user-space for x86 albeit the kernel has been compiled with CONFIG_X86_TSC disabled would
> 
> certainly lead to runtime problems if uncaught, since Xenomai and the application would not agree on the high precision clock to use for their timings. 
> 
> Options that need perfect matching between both sides are marked as "strong" in the following lists, others that may differ are marked as "weak".
> ...

 

```
# KERNEL_DIR=/usr/src/linux-2.6.28-xenomai-r5 emerge -pv xenomai

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] sys-libs/xenomai-2.4.9  USE="-debug -smp -uvm -x86-sep -x86-tsc" 0 kB [1]

Total: 1 package (1 new), Size of downloads: 0 kB

Portage tree and overlays:

 [0] /usr/portage

 [1] /usr/portage/local/mesEbuilds
```

Let's check the kernel configuration :

```
# grep -i TSC /usr/src/linux/.config

# CONFIG_M586TSC is not set

CONFIG_X86_TSC=y

PCTRAVAIL ~ # grep -i SEP /usr/src/linux/.config

PCTRAVAIL ~ # grep -i NPTL /usr/src/linux/.config

PCTRAVAIL ~ # grep -i UVM /usr/src/linux/.config

PCTRAVAIL ~ # grep -i virtual /usr/src/linux/.config

# CONFIG_FB_VIRTUAL is not set

CONFIG_VIRTUALIZATION=y

# grep -i SMP /usr/src/linux/.config

CONFIG_BROKEN_ON_SMP=y

# CONFIG_SMP is not set

CONFIG_X86_FIND_SMP_CONFIG=y

# CONFIG_X86_VSMP is not set
```

I don't catch all of it, but for sure I have to set the x86-tsc use flag - probably not smp nor x86-sep - and I don't care about debugging xenomai. As I want skins (rtai one), I use uvm cf Ref. (2.7).

Set appropriate USE flags for xenomai :

```
echo sys-libs/xenomai x86-tsc uvm >> /etc/portage/package.use
```

Just to check :

```
# KERNEL_DIR=/usr/src/linux-2.6.28-xenomai-r5 emerge -pv xenomai

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] sys-libs/xenomai-2.4.9  USE="uvm x86-tsc -debug -smp -x86-sep" 0 kB [1]
```

Let's actually emerge :

```
# ebuild xenomai-2.4.9.ebuild manifest

# KERNEL_DIR=/usr/src/linux-2.6.28-xenomai-r5 emerge xenomai
```

Ok, it has emerged. Analysing the emerge log, I have :

```
configure: WARNING: unrecognized options: --with-linux-dir, --disable-uvm
```

 I am not a ./configure expert, but it seems it has ignored KERNEL_DIR=/usr/src/linux-2.6.28-xenomai-r5 in our emerge command, and used the simlink /usr/src/linux instead. As I selected it before, that's ok. But this ebuild is not very good and should be used and/or adapted with care.

List of warnings :

```
# grep -i warning /var/log/portage/sys-libs\:xenomai-2.4.9\:20090830-230019.log | uniq

configure: WARNING: unrecognized options: --with-linux-dir, --enable-uvm

libtool: install: warning: remember to run `libtool --finish /usr/xenomai/lib'

```

Let's do libtool stuff, which install the libraries :

```
libtool --finish /usr/xenomai/lib
```

Note : first, I did not set the uvm use flag, and I got a warning even for the native skin.

Let's reboot now and see.....Last edited by lalebarde on Sun Aug 30, 2009 10:55 pm; edited 2 times in total

----------

## lalebarde

It boots, nothing looks broken, my favorite bzflag works. Let's check further :

```
# dmesg | grep EE

# dmesg | grep WW
```

are both clean.

I have now to get some test packages from xenomai to see the real thing. 

See you soon.

----------

## John R. Graham

 *lalebarde wrote:*   

> ...RTAI (fork of RTLinux for GPL issues)...

 Turns out not to be the case.RTLinux runs Linux as a low priority thread under a small microkernel-based RTOS that provides hard real time response.  There are mechanisms for communications between the RTOS-hosted real time threads and the Linux Kernel.

RTAI is a kernel patch set that reduces kernel interrupt latency.They're totally different animals.  I investigated them both a few years ago.  At that time, RTAI was less mature and RTLinux provided lower guaranteed latency.  I would bet that the latter point is still true.  It also seems to me that it is much easier to prove assertions about a small RTOS than about a complex beast like the Linux kernel.

 *lalebarde wrote:*   

> ...RTLinux (now proprietary and owned by Wind River Systems)...

 RTLinux was never totally free, nor GPL'd.  There is a version that appears to meet (at least much of) the definition of open source, though.  It's not GPL'd, but is freely available for non-commercial use.  See http://www.rtlinuxfree.com/.

- John

----------

## lalebarde

Thanks for contributing John,

 *john_r_graham wrote:*   

>  *lalebarde wrote:*   ...RTAI (fork of RTLinux for GPL issues)... Turns out not to be the case.RTLinux runs Linux as a low priority thread under a small microkernel-based RTOS that provides hard real time response.  There are mechanisms for communications between the RTOS-hosted real time threads and the Linux Kernel.
> 
> RTAI is a kernel patch set that reduces kernel interrupt latency.They're totally different animals. 

 

From Lipardi and Scordino :

 *http://feanor.sssup.it/~lipari/papers/ANIPLA_scordino_lipari.pdf wrote:*   

> These techniques can be grouped in the following two classes of approaches:
> 
>    1) Interrupt Abstraction, which adds a new abstraction layer beneath the kernel to take full control of interrupts and system timers. This approach creates a hard RTOS that executes Linux as a background task.
> 
>    2) Kernel Preemption approaches, that make the behaviour of the system more deterministic, by improving kernel preemption, response times and timing resolution.

 

Interrupt Abstraction : (your point 1) *same wrote:*   

> 
> 
> The Interrupt Abstraction approach has been successfully implemented in some existing RTOSs, the most famous being RTLinux and RTAI.
> 
> ......................................................................................................................................................................................................................
> ...

 

Kernel Preemption approaches : (your point 2) *same wrote:*   

> 
> 
> A. Reducing Kernel Latency
> 
> Two different approaches were proposed to reduce kernel latency in the 2.4 version of the Linux kernel. These two approaches were the Low Latency Patch and the Preemptible Kernel Patch, respectively. The former patch was introduced by Ingo Molnar and then maintained by Andrew Morton [11].
> ...

 

Other authors :

 *http://www.ibm.com/developerworks/linux/library/l-real-time-linux/ wrote:*   

> The thin-kernel (or micro-kernel) approach uses a second kernel as an abstraction interface between the hardware and the Linux kernel (see Figure 3). The non-real-time Linux kernel runs in the background as a lower-priority task of the thin kernel and hosts all non-real-time tasks. Real-time tasks run directly on the thin kernel.
> 
> ......................................................................................................................................................................................................................
> 
> Examples of this approach include RTLinux (now proprietary and owned by Wind River Systems), Real-Time Application Interface (RTAI), and Xenomai.

 

 *same wrote:*   

> Where the thin kernel approach relies on a minimized kernel that includes task management, the nano-kernel approach goes a step further by minimizing the kernel even more. In this way, it's less a kernel and more a hardware abstraction layer (HAL).
> 
> ......................................................................................................................................................................................................................
> 
> An example of the nano-kernel approach is the Adaptive Domain Environment for Operating Systems (ADEOS). ADEOS supports multiple concurrent operating systems running simultaneously. When hardware events occur, ADEOS queries each operating system in a chain to see which will handle the event.

 

Note : Now, both RTAI and Xenomai uses ADEOS.

 *same wrote:*   

> Real time in the standard 2.6 kernel : While all the approaches discussed so far are architecturally interesting, they all operate around the periphery of the kernel.
> 
> ......................................................................................................................................................................................................................
> 
> The new configuration option CONFIG_PREEMPT changes this behavior of the kernel by allowing processes to be preempted if high-priority work is available to do
> ...

 

On RTAI site :

 *https://www.rtai.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=2&MMN_position=2:2 wrote:*   

> The Realtime Application Interface consists mainly of two parts:
> 
> A patch to the Linux kernel which introduces a hardware abstraction layer 
> 
> A broad variety of services which make realtime programmers' lifes easier

 

 *https://www.rtai.org/index.php?module=documents&JAS_DocumentManager_op=viewDocument&JAS_Document_id=3 wrote:*   

> RTAI offers the same services of the Linux kernel core, adding the features of an industrial real time operating system. It consists basically of an interrupt dispatcher: RTAI mainly traps the peripherals interrupts and if necessary re-routes them to Linux. It is not an intrusive modification of the kernel; it uses the concept of HAL (hardware abstraction layer) to get information from Linux and to trap some fundamental functions. This HAL provides few dependencies to Linux Kernel. This leads to a simple adaptation in the Linux kernel, an easy RTAI port from version to version of Linux and an easier use of other operating systems instead of RTAI. RTAI considers Linux as a background task running when no real time activity occurs.

 

Where I agree with you John is that there are differences thought between RTLinux and RTAI concepts. Schematics in http://dslab.lzu.edu.cn:8080/members/puyq/doc/multi-core.pdf makes that clearer than what I could explain.

My bad wording with "fork" came from (I have corrected the 1st post) :  *http://en.wikipedia.org/wiki/RTAI wrote:*   

> RTAI versions over 3.0 use an Adeos kernel patch, slightly modified in the x86 architecture case, providing additional abstraction and much lessened dependencies on the 'patched' operating system. Adeos is a kernel patch comprising an Interrupt Pipeline where different Operating System Domains register interrupt handlers. This way, RTAI can transparently take over interrupts while leaving the processing of all others to Linux. Use of Adeos also frees RTAI from patent restrictions caused by RTLinux project.

 

Concerning the licence of RTLinux :

 *http://www.rtlinuxfree.com/ wrote:*   

> RTLinuxFree.com provides a mechanism for downloading, evaluating, and using RTLinux technology, subject to the terms and restrictions of the Open RTLinux Patent License. The license requires that all applications using the free RTLinux download be GPL licensed, and also requires that application source code be made publicly available on the Web. In exchange, Wind River provides royalty-free use of the patented RTLinux process.

 

----------

## lalebarde

HOWTO BUILD XENOMAI WITH GENTOO-SOURCES - step 3

Additional references :

(2.8 ) http://www.xenomai.org/index.php/Non-root_RT

(2.9) http://www.xenomai.org/index.php/Examples

To allow non-root users to access Xenomai skins from user space, follow Ref. (2.8 ).

Add xenomai group into /etc/group, and put you in that group. Do whatever solution proposed by Ref. (2.8 ). As I don't know how to perform the two first, I have used the third one :

```
# echo "<xenomai_gid>" > /sys/module/xeno_nucleus/parameters/xenomai_gid
```

Where xenomai_gid is the number you put into /etc/group to declare the xenomai group.

EDIT : 2009-09-05 - Moreover, in your grub.conf, in the kernel line, you shall add the option : ro xeno_nucleus.xenomai_gid=<xenomai_gid>

Here is what looks like mine :

```
title kernel-2.6.28-xenomai-r5-2009-08-30 - root(hd0,4)-root=/dev/sda6

root (hd0,4)

kernel /kernel-2.6.28-xenomai-r5-2009-08-30 root=/dev/sda6 quiet CONSOLE=/dev/tty1 splash=quiet ro xeno_nucleus.xenomai_gid=2013
```

Third step : Testing

I found tests in Ref. (2.9), and put them into /opt/xenomaiExamples, and built the test native.

Here is the result :

```
# ./trivial-periodic 

Time since last turn: 1000.009509 ms

Time since last turn: 1000.000690 ms

Time since last turn: 1000.000035 ms

Time since last turn: 1000.006100 ms

Time since last turn: 999.996519 ms

Time since last turn: 999.996952 ms

Time since last turn: 1000.005086 ms

Time since last turn: 999.994744 ms

Time since last turn: 1000.000464 ms

Time since last turn: 1000.003610 ms

Time since last turn: 999.996363 ms

Time since last turn: 999.999673 ms

Time since last turn: 1000.000425 ms
```

Not too bad isn't it, with my old P4 ?

```
# uname -a

Linux PCTRAVAIL 2.6.28-xenomai-r5 #1 PREEMPT Sun Aug 30 13:07:05 CEST 2009 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
```

Let's see with some load to put cpu and memory on the knees. Here is what I am going to launch, and run the test in the time between :

```
$ cat loadtest 

oowriter&

echo oowriter started

firefox&

echo firefox started

stellarium&

echo stellarium started

amarok&

echo amarok started

gimp&

echo gimp started

thunderbird&

echo thunderbird started

ooimpress&

echo ooimpress started

blender&

echo blender started

celestia&

echo celestia started

vlc&

echo vlc started

qjackctl&

echo qjackctl started

qsynth&

echo qsynth started

skype&

echo skype started

eclipse&

echo eclipse started
```

Here is the result :

```
$ cat trace.log 

Time since last turn: 1000.019396 ms

Time since last turn: 999.994378 ms

Time since last turn: 999.999117 ms

Time since last turn: 1000.002579 ms

Time since last turn: 999.999327 ms

Time since last turn: 999.996574 ms

Time since last turn: 999.997978 ms

Time since last turn: 1000.001641 ms

Time since last turn: 1000.022208 ms

Time since last turn: 999.976710 ms

Time since last turn: 1000.006282 ms

Time since last turn: 999.998138 ms

Time since last turn: 999.999651 ms

Time since last turn: 1000.001270 ms

Time since last turn: 1000.001224 ms

Time since last turn: 999.999348 ms

Time since last turn: 999.999135 ms

Time since last turn: 1000.000426 ms

Time since last turn: 999.999373 ms

Time since last turn: 1000.001413 ms

Time since last turn: 999.994435 ms

Time since last turn: 1000.004039 ms

Time since last turn: 999.995384 ms

Time since last turn: 1000.009078 ms

Time since last turn: 999.993850 ms

Time since last turn: 999.998404 ms

Time since last turn: 999.999426 ms

Time since last turn: 1000.007161 ms

Time since last turn: 999.995362 ms

Time since last turn: 999.998899 ms

Time since last turn: 999.998200 ms

Time since last turn: 1000.004384 ms

Time since last turn: 1000.000313 ms

Time since last turn: 1000.001924 ms

Time since last turn: 999.995573 ms

Time since last turn: 1000.000974 ms

Time since last turn: 1000.002641 ms

Time since last turn: 999.999943 ms

Time since last turn: 999.995131 ms

Time since last turn: 1000.000223 ms

Time since last turn: 1000.004118 ms

Time since last turn: 1000.003183 ms

Time since last turn: 999.998523 ms

Time since last turn: 1000.001636 ms

Time since last turn: 999.997871 ms

Time since last turn: 999.994112 ms

Time since last turn: 1000.007934 ms

Time since last turn: 1000.000219 ms

Time since last turn: 999.999522 ms

Time since last turn: 999.995061 ms

Time since last turn: 999.997966 ms

Time since last turn: 1000.007904 ms

Time since last turn: 999.997148 ms

Time since last turn: 999.994022 ms

Time since last turn: 1000.012600 ms

Time since last turn: 999.990399 ms

Time since last turn: 999.999516 ms

Time since last turn: 1000.000198 ms

Time since last turn: 1000.009290 ms

Time since last turn: 999.990820 ms

Time since last turn: 1000.000486 ms

Time since last turn: 1000.000177 ms

Time since last turn: 999.998795 ms

Time since last turn: 1000.004743 ms

Time since last turn: 999.993857 ms

Time since last turn: 1000.000046 ms

Time since last turn: 1000.002427 ms

Time since last turn: 1000.002000 ms

Time since last turn: 999.998206 ms

Time since last turn: 999.999825 ms

Time since last turn: 1000.004354 ms

Time since last turn: 999.990772 ms

Time since last turn: 1000.003745 ms

Time since last turn: 1000.005295 ms

Time since last turn: 999.996680 ms

Time since last turn: 1000.002270 ms

Time since last turn: 999.998348 ms

Time since last turn: 999.998453 ms

Time since last turn: 1000.000964 ms

Time since last turn: 999.995738 ms

Time since last turn: 1000.004570 ms

Time since last turn: 999.996268 ms

Time since last turn: 1000.004212 ms

Time since last turn: 999.995428 ms

Time since last turn: 1000.000450 ms

Time since last turn: 1000.003527 ms

Time since last turn: 999.996994 ms

Time since last turn: 1000.000428 ms

Time since last turn: 999.998567 ms
```

And some stats : Standard Deviation = 0.005752 ms = 6 us, max = 0,023290 ms = 23 us.

I am impressed   :Very Happy:  ! Of course, the task is the most basic as possible, but it does it on heavy load. 

Next, I will install uperlevel tools : xenoscope, Orocos, RTAI-Lab, Cleopatre, and play with Scilab/Scicos.Last edited by lalebarde on Sun Sep 06, 2009 8:50 am; edited 2 times in total

----------

## lalebarde

 *lalebarde wrote:*   

> To allow non-root users to access Xenomai skins from user space, follow Ref. (2.8 ).
> 
> Add xenomai group into /etc/group, and put you in that group. Do whatever solution proposed by Ref. (2.8 ). As I don't know how to perform the two first, I have used the third one :
> 
> ```
> ...

 

It does not work for me, I have had to run my test from root. I get that from user lalebarde :

```
$ ./trivial-periodic 

Xenomai: binding failed: Operation not permitted.
```

 I have to investigate and/or try the other methods.

Besides, shutdown does not look clean. Is there exist an equivalent of dmesg at shutdown ?

----------

## lalebarde

Concerning the problem preventing me as a non-root users to access Xenomai skins from user space, I found the solution here : http://www.xenomai.org/index.php/Xenomai_quick_build_quide

I have edited step 3 with EDIT : 2009-09-05 to correct the howto.

----------

