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

[Philippe Gerum <rpm@xenomai.org>]

Randy Smith wrote:
> 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.)
>

Make sure to read this then (also includes simple porting tips from RTAI 
to the native API):

http://download.gna.org/xenomai/documentation/branches/v2.1.x/pdf/Native-API-Tour.pdf

> 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

Make sure reading configure's output that the right ppc (cross-)compiler 
is found and used.

> 
> 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
> 

This part is to build the user-space (only) support, so #1 is the right 
one. Since 2.1, Xenomai clearly splits the kernel side from the 
user-space support, so building the RT subsystem is just a matter of 
configuring yet-another-linux-subsystem using the regular Linux Kconfig 
interface, instead of fiddling with yet-another-nonstandard-kconfig. It 
also makes possible to build such RT subsystem statically into the 
kernel, and not only as external modules, which is good for our poor TLBs.

If we keep on being good boys in the future and don't change the skin 
system call numbers and prototypes each time at full moon, we might even 
reach some kind of reasonably stable ABI, so that the user-space stuff 
could run on the largest possible set of older versions of the kernel side.

README.INSTALL gives simple examples for building the user-space support 
for various archs; maybe this would help.

> ???
> 
> 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.
> 

Something looks like being badly trashed in your source tree, which 
would be quite possible if #2 is current.

> 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).
>>
>>   
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.