public inbox for elix@sourceware.org
 help / color / mirror / Atom feed
From: Stuart Hughes <sehughes@zentropix.com>
To: elix <elix@sourceware.cygnus.com>
Cc: Michael Tiemann <tiemann@cygnus.com>
Subject: EL/IX API, Real-Time and Linux
Date: Fri, 19 Nov 1999 09:18:00 -0000	[thread overview]
Message-ID: <383586CD.7E28325A@zentropix.com> (raw)

Hi all,

I was very interested in the announcement or the EL/IX project and
applaud its goal of providing a standard and consistent API for embedded
systems.

My particular area of interest is realtime systems that are large scale
enough to host standard Linux (e.g not deeply embedded systems, which
would be better addressed by OSes such as ecos).  These systems are
often referred to as desktop realtime, although some of the more capable
single board computers fall into this category.

As some of you know RTLinux and RTAI provide a means of programming hard
realtime task in kernel space modules (using fundamentally the same
technique).  

There has been a lot of work done in the last 6 months, to a fairly full
implementation of POSIX 1003.1c (pthreads) for RTAI, which includes
support for mutexes (including priority inheritance) and condition
variables.  This is a good start, but still leaves a lot of the other
recommendations of the EL/IX document unaddressed.  In particular
realtime tasks cannot directly support the Base UNIX API (e.g. read,
write, open, close etc).  Although this may seem a big problem, it may
not be quite so bad as RTAI has a facility known as sysrq (system
requests) that may be used to pend calls to Linux, that will then be run
when the realtime section returns.  This is one approach that may allow
the realtime section to gain access to the non-realtime services of
Linux.

I would be interested to hear from anyone who would be interested in
contributing to help further develop the RTAI POSIX package so it can
grow to become conformant to the EL/IX API.  Also I would like to hear
what people think about realtime threads accessing non-realtime services
(such as disk) and mechanisms that can be employed to make sure that
this won't destroy the realtime behaviour of the system (e.g code
analysis tools to highlight prioritisation problems, or mandating
non-blocking I/O calls for realtime threads ?).

Further information on RTAI can be obtained from http://www.rtai.org/ . 
Details of the POSIX module can be found in the posix subdirectory of
later RTAI distributions.

Regards, 

Stuart Hughes,
Zentropix.
http://www.zentropix.com/

                 reply	other threads:[~1999-11-19  9:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=383586CD.7E28325A@zentropix.com \
    --to=sehughes@zentropix.com \
    --cc=elix@sourceware.cygnus.com \
    --cc=tiemann@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).