RTLinux workshop and EL/IX press coverage on EETimes

RTLinux workshop and EL/IX press coverage on EETimes

[Paul Beskeen]

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.

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

[Stuart Hughes]

Paul Beskeen wrote:
> 
> 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.
> 

Indeed, the RealTime Linux workshop was a great success, and Cynus's
involvement was warmly appreciated.  Zentropix has been an advocate of
the EL/IX initiative from the beginning, and as the principal RealTime
Linux company, we look forward to work with all the supporters of EL/IX
and the RealTime Linux community to ensure its adoption for the RealTime
Linux standards based API.

Regards, Stuart

-- 
Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for more info about Linux and
RealTime

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

[Nick Garnett]

"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

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

[Mark Johannes]

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

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

[Stuart Hughes]

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

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

[Nick Garnett]

Mark Johannes <mark.johannes@oarcorp.com> writes:

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

Yes, the POSIX profile needs to be looked at and included
somehow. When I get a copy I'll work on this.


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

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

[Nick Garnett]

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

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

[Stuart Hughes]

Nick Garnett wrote:
> 
> Stuart Hughes <sehughes@zentropix.com> writes:
> 
> > 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.

I agree, it shouldn't be too difficult.


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

You're right, if a realtime task made a call to a Linux kernel service,
is not longer running at a realtime priority and this would need to be
made very clear.  One of the ideas we had was to reserve a group of
priorities that would be 'kernel priority', and say that any RT task
calling these services must run at kernel priority, to enforce this we
would need some checking (maybe simply forcing the need to link to a
library).  At the moment, this is only an idea, but I would love to see
some kind of transparent access to the Linux kernel from RT to make the
programmer feel that he/she is developing in a coherent environment.

As you mention, the C library is also a problem and there is a need for
(and we have been exploring) a libc_rt.a library.  Already some brave
people have been linking in some of the static libraries into their
applications (libm.a is common).  Generally this works, but at the end
of that day you need to know what you are letting yourself in for.

BTW Nick, can you let me have another e-mail address for you
(nickg@cygnus.co.uk has been bouncing).

Regards, Stuart.

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

[Nick Garnett]

Stuart Hughes <sehughes@zentropix.com> writes:

> You're right, if a realtime task made a call to a Linux kernel service,
> is not longer running at a realtime priority and this would need to be
> made very clear.  One of the ideas we had was to reserve a group of
> priorities that would be 'kernel priority', and say that any RT task
> calling these services must run at kernel priority, to enforce this we
> would need some checking (maybe simply forcing the need to link to a
> library).  At the moment, this is only an idea, but I would love to see
> some kind of transparent access to the Linux kernel from RT to make the
> programmer feel that he/she is developing in a coherent environment.
>

I think this is important. The "two level" model that currently exists
is, as someone on /. said yesterday, a bit of a hack. The more that
can be done to produce a single seamless programmer model the better.

> As you mention, the C library is also a problem and there is a need for
> (and we have been exploring) a libc_rt.a library.  Already some brave
> people have been linking in some of the static libraries into their
> applications (libm.a is common).  Generally this works, but at the end
> of that day you need to know what you are letting yourself in for.
> 
> BTW Nick, can you let me have another e-mail address for you
> (nickg@cygnus.co.uk has been bouncing).
> 

Really? That is my canonical address and should work. You can try
nickg@cygnus.com, but that is really just a forward to my .uk address.

It may be that you are accidentally being zapped by out spam filter.
I have just talked to our sysadmin and that is exactly what is
happening. It appears that your IP address is in a range that someone
sometime decided we didn't like. Probably as a result of spam from
another user of your ISP. It should be fixed now. If you get any more
bounces, let me know.

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