[Xenomai-help] Porting / API Questions

[Xenomai-help] Porting / API Questions

[Jeff Webb]

I am attempting to port a real-time simulation from rtlinux3.2-pre3 (GPL) to xenomai.  The application consists of a kernel module, and a user-space application.  I would like to port the application to xenomai with as few changes as possible, and then make improvements in incremental steps.  I am currently working on a Fedora Core I, Linux-2.4.32 / xenomai-2.1-rc4 system.

In this simulation, we use the rtlinux POSIX-like API for threads, timing, and writing-to / reading-from real-time FIFOs.  It looks like the xeno_posix API will allow me to port the thread and timing code with very few (if any) changes.  There does not appear to be a kernel-space version of read and write for use on xenomai pipes.  Am I missing something?

I noticed that the rtai API appears to support real-time FIFOs, much like the old RTLinux API.  In light of this discovery, I changed my RT-Linux code to use rtf_get and rtf_put calls (instead of read/write).  This code seems to compile for xeno_rtai without too much trouble.

Is it okay to use the POSIX API for threads and timing, and the rtai API for FIFOs?  It seems like this is working, but I want to make sure that there are no hidden problems.

I have compiled my application for xenomai.  The kernel module loads fine, and the userspace application runs as well.  The problem I am having now is creating a large FIFO, which is why I wrote the previous email.

Any input on this porting project would be appreciated.  Thanks!

-Jeff

Re: [Xenomai-help] Porting / API Questions

[Ulrich Schwab]

On Wednesday 06 September 2006 23:22, Jeff Webb wrote:
> I am attempting to port a real-time simulation from rtlinux3.2-pre3 (GPL)
> to xenomai.  The application consists of a kernel module, and a user-space
> application.  I would like to port the application to xenomai with as few
> changes as possible, and then make improvements in incremental steps.  I am
> currently working on a Fedora Core I, Linux-2.4.32 / xenomai-2.1-rc4
> system.
Why not the latest version of xenomai (2.2) ? 
>
> In this simulation, we use the rtlinux POSIX-like API for threads, timing,
> and writing-to / reading-from real-time FIFOs.  It looks like the
> xeno_posix API will allow me to port the thread and timing code with very
> few (if any) changes.  There does not appear to be a kernel-space version
> of read and write for use on xenomai pipes.  Am I missing something?
When I did the same switch (9 month ago now) I choose to combine
the kernel / user space split in one application and switched to the native 
API at the same time.
I think it was a good decision, since now the application is independent of 
the exact kernel version and is easier to debug.
Only the driver for the analog and digital I/O is still a kernel module (RTDM)

The RT kernel threads of the original version are now threads of the user 
space app running in primary mode. This means the split between RT/non-RT
is basically the same as before, but now they all run in user space.

>
> I noticed that the rtai API appears to support real-time FIFOs, much like
> the old RTLinux API.  In light of this discovery, I changed my RT-Linux
> code to use rtf_get and rtf_put calls (instead of read/write).  This code
> seems to compile for xeno_rtai without too much trouble.
>
> Is it okay to use the POSIX API for threads and timing, and the rtai API
> for FIFOs?  It seems like this is working, but I want to make sure that
> there are no hidden problems.
>
> I have compiled my application for xenomai.  The kernel module loads fine,
> and the userspace application runs as well.  The problem I am having now is
> creating a large FIFO, which is why I wrote the previous email.
Why do You need a FIFO this large ?
Why not using shared memory for the data, and the FIFO for passing
signals/commands ?

Ulrich
>
> Any input on this porting project would be appreciated.  Thanks!
>
> -Jeff
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Porting / API Questions

[Jeff Webb]

Ulrich Schwab wrote:
> When I did the same switch (9 month ago now) I choose to combine
> the kernel / user space split in one application and switched to the native 
> API at the same time.
> I think it was a good decision, since now the application is independent of 
> the exact kernel version and is easier to debug.
> Only the driver for the analog and digital I/O is still a kernel module (RTDM)
> 
> The RT kernel threads of the original version are now threads of the user 
> space app running in primary mode. This means the split between RT/non-RT
> is basically the same as before, but now they all run in user space.

I'm glad to hear that you were successful with porting your application!  I plan to take a similar approach eventually, but I want to do things one small step at a time.

> Why do You need a FIFO this large ?

I have a whole lot of data coming over the FIFO at a very high rate.  The user-space side also has some graphics routines that have a long latency in certain situations.  The amount of data transferred could be reduced substantially, but not without major changes to the simulation, which I cannot afford to do at the moment.

> Why not using shared memory for the data, and the FIFO for passing
> signals/commands ?

I need to log data, plot, and do other things at certain exact simulation times.  Using shared memory, I cannot guarantee that I will be able to get data with the timestamp I need.  The real-time/user-space partitioning of our simulation is not at all optimal.  Switching to userspace real-time will allow me to do things in a much cleaner way.

Thanks for your input,

Jeff

Re: [Xenomai-help] Porting / API Questions

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]

Jeff Webb wrote:
> 
> I am attempting to port a real-time simulation from rtlinux3.2-pre3
> (GPL) to xenomai.  The application consists of a kernel module, and a
> user-space application.  I would like to port the application to xenomai
> with as few changes as possible, and then make improvements in
> incremental steps.  I am currently working on a Fedora Core I,
> Linux-2.4.32 / xenomai-2.1-rc4 system.
> 
> In this simulation, we use the rtlinux POSIX-like API for threads,
> timing, and writing-to / reading-from real-time FIFOs.  It looks like
> the xeno_posix API will allow me to port the thread and timing code with
> very few (if any) changes.  There does not appear to be a kernel-space
> version of read and write for use on xenomai pipes.  Am I missing
> something?

For what side, RT or non-RT? Or what service (function name) is missing
precisely?

> 
> I noticed that the rtai API appears to support real-time FIFOs, much
> like the old RTLinux API.  In light of this discovery, I changed my
> RT-Linux code to use rtf_get and rtf_put calls (instead of read/write). 
> This code seems to compile for xeno_rtai without too much trouble.
> 
> Is it okay to use the POSIX API for threads and timing, and the rtai API
> for FIFOs?  It seems like this is working, but I want to make sure that
> there are no hidden problems.

I haven't used the RTAI skin so far, but from a look at the FIFO code I
cannot find any reasons for not using it with other skins.

> 
> I have compiled my application for xenomai.  The kernel module loads
> fine, and the userspace application runs as well.  The problem I am
> having now is creating a large FIFO, which is why I wrote the previous
> email.
> 
> Any input on this porting project would be appreciated.  Thanks!
> 
> -Jeff
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Porting / API Questions

[Jeff Webb]

Jan Kiszka wrote:
>> In this simulation, we use the rtlinux POSIX-like API for threads,
>> timing, and writing-to / reading-from real-time FIFOs.  It looks like
>> the xeno_posix API will allow me to port the thread and timing code with
>> very few (if any) changes.  There does not appear to be a kernel-space
>> version of read and write for use on xenomai pipes.  Am I missing
>> something?
> 
> For what side, RT or non-RT? Or what service (function name) is missing
> precisely?

RT-Linux has a mostly POSIX interface to rt-fifos.  You must create/delete them using the non-standard rtf_create/rtf_destroy, but after that, you can open, close, read, and write them using a file descriptor.  I was wondering if this mapping exists for the real-time Xenomai POSIX API.  I am specifically asking about kernel-space right now, but I would also like to know if this sort of thing is supported from user-space real-time as well.

-Jeff

Re: [Xenomai-help] Porting / API Questions

[Gilles Chanteperdrix]

Jeff Webb wrote:
 > Jan Kiszka wrote:
 > >> In this simulation, we use the rtlinux POSIX-like API for threads,
 > >> timing, and writing-to / reading-from real-time FIFOs.  It looks like
 > >> the xeno_posix API will allow me to port the thread and timing code with
 > >> very few (if any) changes.  There does not appear to be a kernel-space
 > >> version of read and write for use on xenomai pipes.  Am I missing
 > >> something?
 > > 
 > > For what side, RT or non-RT? Or what service (function name) is missing
 > > precisely?
 > 
 > RT-Linux has a mostly POSIX interface to rt-fifos.  You must create/delete them using the non-standard rtf_create/rtf_destroy, but after that, you can open, close, read, and write them using a file descriptor.  I was wondering if this mapping exists for the real-time Xenomai POSIX API.  I am specifically asking about kernel-space right now, but I would also like to know if this sort of thing is supported from user-space real-time as well.

There is no such thing in Xenomai POSIX API. The native API proposes rt_pipes:
http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Porting / API Questions

[Gilles Chanteperdrix]

Jeff Webb wrote:
 > Is it okay to use the POSIX API for threads and timing, and the rtai API for FIFOs?  It seems like this is working, but I want to make sure that there are no hidden problems.

There should be no problem mixing the POSIX API with other
interfaces. If a POSIX service absolutely requires a POSIX skin thread,
it will return an error of EPERM when called from an invalid
context. Now, if you want to exchange messages "the POSIX way", you can
use POSIX message queues.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Porting / API Questions

[Jeff Webb]

Gilles Chanteperdrix wrote:
> There should be no problem mixing the POSIX API with other
> interfaces. If a POSIX service absolutely requires a POSIX skin thread,
> it will return an error of EPERM when called from an invalid
> context. 

Thanks!

> Now, if you want to exchange messages "the POSIX way", you can
> use POSIX message queues.

I will probably make this switch, but I would rather get the code ported to xenomai with as few changes as possible.  After that, I will try to go "the POSIX way" to future-proof the code as much as possible.

-Jeff

Re: [Xenomai-help] Porting / API Questions

[Gilles Chanteperdrix]

Jeff Webb wrote:
 > I will probably make this switch, but I would rather get the code ported to xenomai with as few changes as possible.  After that, I will try to go "the POSIX way" to future-proof the code as much as possible.

The most future-proof design is probably, as outlined by Ulrich, to only
develop drivers in kernel-space using the RTDM skin, and to use the
posix or native skins in user-space. Note that the RTDM and posix skins
are integrated, I mean that once you create a driver with RTDM, you
can access it in user-space with open, read, write, ioctl and close.

-- 


					    Gilles Chanteperdrix.