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

[Nick Garnett <nickg@cygnus.co.uk>]

Stuart Hughes <sehughes@zentropix.com> writes:

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

That's good. The more standardized moduled we have, the less effort it
will be to get the real time Linux users to adopt the API.

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

This is what I had understood from the workshop. I guess that the work
to get this into a POSIX API with the correct semantics should not be
too hard.

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

I had missed the mailbox mechanism. Being able to call standard kernel
functions from the real time module would make use of the API a lot
easier, although there would still be the issue of C library functions
to consider. Also, since an RT thread would presumably cease to be
real time while calling a kernel function, it is important to indicate
these in the API spec.

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

Yes, I was worried about how to handle the "go periodic" stuff. This
seems like a promising solution. I believe that there is also some
work going on to extend the POSIX API and interfaces to cope with
schedulers other than the standard set. However, I do not know
anything about this.


-- 
Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk