Re: RTLinux workshop and EL/IX press coverage on EETimes

[Stuart Hughes <sehughes@zentropix.com>]

Nick Garnett wrote:
> 
> As a followup to this I would like to try and bootstrap some
> discussion on how we should improve/ammend/update the API spec to
> accomodate both real time Linux requirements as well as more general
> real time operating systems. Although "embedded" and "real time" are
> orthogonal, they often go together, so it makes sense to consider the
> latter at this point.
> 
> The main problem with the current real time Linux implementations is
> that the real time portions of the application are separated from the
> non-realtime portions. Real time components are built into a kernel
> module while non-real time components go into a conventional process.
> The only communication allowed is via FIFOs and shared memory. While
> this may change in the future, the current restrictions will apply for
> some time to come.
> 
> The main approach I want to take in handling this is to start by
> identifying a "real time" subset of the API. This would indicate those
> functions that can be expected to exhibit real time properties. For
> real time Linux these would be the functions that could be called in
> the real time module. For other operating systems these would be the
> functions that provide real time services, other functions would not
> be expected to be real time.
> 
> A provisional list of the real time subset would consist of:
> 
> POSIX pthread functions
> POSIX mutex and condition variables
> POSIX semaphore functions
> POSIX message queue functions
> 
> At present there is no clear analog in the POSIX spec for the real
> time Linux FIFOs, although maybe they can be mapped onto message
> queues in some way. As far as the API is concerned, real time Linux
> programs would be modelled as two "processes" one containing the real
> time portion and one containing the non real time portion, connected
> by message queues and shared memory.
> 
> These are just some initial ideas to try and get some discussion
> going, comments and criticisms to the list please.


Hi Nick,

Thanks for your analysis, which is spot on.  So far RTAI has support
for:

POSIX pthread functions
POSIX mutex and condition variables

We have just submitted a POSIX queues module for inclusion in RTAI.

This leaves semaphores, which are available but not using the standard
POSIX API.  I think that it should be possible to provide a wrapper to
support this API.

Regarding the communications between the RT kernel and regular user
space processes, what you say is correct, however there is also a
mailbox mechanism for IPC communication.  Also we are looking at a
method of providing transparent access at the API level to the standard
kernel syscalls, this would mean that for realtime tasks they would then
be running at kernel priority rather than being true realtime tasks.  If
this is possible I think it is attractive, as from a programming point
of view you wouldn't have the extra overhead of worrying about
communication with the Linux system proper.

Another problem that needs to be addressed is how to support the
periodic nature of tasks, that is the norm in RealTime tasks.  Our first
thoughts are to provide a POSIX timers/clocks module.  For example, one
possibility is to make use of the pthreads notification mechanism
SIGEV_THREAD this would allow a pthread to block on a condition variable
which is signaled by a POSIX timer expiring.  This is just one route and
I would be glad to hear if anyone has thoughts on this.

Regards, Stuart