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

[Mark Johannes <mark.johannes@oarcorp.com>]

Nick and All,

I would like to suggest the POSIX.13 Realtime Profiles as a place to look for help
in determining the realtime as opposed to the non-realtime.  In fact, if the group
can formulate another profile, perhaps this should be brought to the PASC
commitee.  In the case that POSIX does not meet our needs, we should standardize
these calls (such as interrupts, etc...) and work to see their incorporation into
the POSIX specifications.

We at OAR are very excited about this new API and wish to provide our assistance
with its definition.  Our typical domain is in the deeply embedded and we have
accumulated a vast knowledge base on how an operating system is to play within
these confines.  We also realize that this operating system must "connect" to the
world through standards and other OSs such as standard Linux, NT and others.

An open standard allows for the PNP that everybody wishes.

Regards,

Mark Johannes
OAR Corporation

Nick Garnett wrote:

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