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

[Stuart Hughes <sehughes at zentropix dot com>]

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.