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

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

"Paul Beskeen" <paulb@cygnus.co.uk> writes:

> Just a quick news update and pointer. Cygnites Nick Garnett and Manfred
> Hollstein recently attended the RTLinux workshop in Vienna and gave a
> presentation on EL/IX. This kick-started discussions on use of the EL/IX API
> within the RTLinux community and ongoing collaboration to try and ensure
> that the EL/IX API spec meets their requirements.
> 
> Enjoy, Paul.
> 
> --
> Real-time Linux developers unite on API
> 
> By Craig Matsumoto
> EE Times
> (12/20/99, 1:24 p.m. EDT)
> 
> VIENNA, Austria - Developers of embedded-Linux systems established some
> common ground at a gathering last week, as they laid the foundation to build
> common threads among their various efforts and also decided to back Cygnus
> Solutions' EL/IX as a common applications programming interface (API) for
> embedded Linux.
> 
> [...]
> 
> See http://www.eet.com/story/OEG19991220S0029 for full story.
> 

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.

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