[Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith <rsmith@domain.hid>]

Thanks Philippe and Fillod for your explanations of the situation wrt 
rtai skin and the gentle nudge to port the code to the native skin.  I 
have decided to go that route as I am going to have to go there 
eventually and there isn't that much code (famous last words.)

I must have installed xenomai incorrectly as my code is not compiling 
without some header files complaining about basic types like atomic_t 
not being defined.  I have a kernel source tree installed in a 
non-standard place, lets call it /home/randy/linux and the xenomai 
package under /home/randy/xenomai-2.1.0.  I have applied the adios patch 
and done the prepare_kernel.sh thing.  So far so good.  I can then do 
make menuconfig and setup the realtime stuff then make uImage and the 
kernel builds correctly (yes, I am cross-compiling for a powerpc).  That 
all works ok.

Where I'm confused is this.  Do I then do something like

$ cd /home/randy
$ mkdir xenomai && cd xenomai
$ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=/home/randy
$ make all
$ make install

OR should I be in the kernel tree such as

$ cd /home/randy/linux
$ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=/home/randy/linux

???

One of the problems I am seeing is that after the make all and make 
install, there is built, an include file tree under /home/randy/include 
and when I include this path on the compiler command line, I get 
circular references such as

#include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h

which should refer to the kernel include of 
/home/randy/linux/include/asm/atomic.h but instead picks up itself again 
and doesn't define the atomic_t (among other things)

Obviously I'm doing something wrong and any help would be appreciated.

Fillod Stephane wrote:
> Philippe Gerum wrote:
>   
>
>> people porting from the RTAI API to Xeno usually switch to Xeno's
>>     
> native 
>   
>> API directly.
>>     
>
> Indeed, switching directly to Xeno native is worth the advice (sigh).
>
>