Hi,
while debating about robots it came out the concept of Hardware
Abstraction Layer (HAL) and Venturcom/Radisys Real Time Application
Interfaces (RTAI) to it.
This suggested to me that it is perhaps the time to debate about
RTLinux/Linux architecture. The hope is that, while keeping clear the
primogeniture of the friends at NMT on RTLinux, RTLinux could become a
real joint development effort in the Linux bazaar style, and not just a
bunch of people using blindly what others gurus made available, eagerly
waiting for patch updates when new kernel releases are made available.
Personally I could warrant that if this was the spirit in the past, the
RTL community would have add a working fpu support, and even a far
better and effective oneshot scheduling, 6/8 months in advance.
With the advent of 2.2.xx people are starting to ask for the inclusion
of RTL patches natively in Linux, and here I'm back to the HAL/RTAI
concept and to the hope of starting a constructive debate within this
community.
In fact the HAL/RTAI architecture is the one to pursue. To support the
point we started an independent development effort that is now matured
in a prototype that works on UP and dual processors.
To this aim, and to roughly explain what is all about, I drafted the
text below as the introduction to a possible install file. Let's see the
response, if any.
>
................... This file contains the list of changes to be made to
a few Linux files to set
up a Real Time Hardware Abstraction Layer (RTHAL). It consists mainly in
establishing a set of pointers to some bsic functions and data
structures that can
subsequently be modified by the Real Time Application Interface module
(RTAI)
to trap Linux interactions with the hardware, so that both can be made
your
slaves.
The decision of making available a list of changes to the Linux kernel
instead of a patch has been preferred as, even if at a first look this
choice may seem less comfortable than a patch, it allows you to be in
full knowledge of what's going on and to fully understand the RTAI
implementation.
In this way you are made completely independent and can readily update
to
future kernel releases, as it has been proven by using this file from
2.2.0-pre1.
It appears to be a long file but that's due only to the duplication of a
lot of, unchanged, code to, hopefully, spot easily where and why the
changes are made.
Once you share this idea, without any apriori bias, it will take more
time to read it than to implement it, i.e. about 10 minutes to carry out
all the stuff.
Please read it and signal any constructive comment back to me.
Apart from the changes below it remains to verify if various readings of
the 8254A timer (in timer_interrupt.c, hd.c, ide.c .....) are used by
Linux in its current duties, and not only at boot initializations.
For now it is sure that in timer_interrupt the 8254A is used
continuously
but the kernel seems to work even without making any modification. See
the
comments to timer_interrupt below if you feel unsafe in leaving the
things
unchanged.
However this is a point to be watched out carefully, even if right now
it seems a non problem or, at least, no arm is done to Linux by
modifying the 8254A counter-0 pacing, as in the periodic timer available
in this distribution.
As already said rtai.c is just an example of implementation of an RTAI,
by
using some basic functions there you can go your own way or, if you
want,
reprogram them in a better way. I'm one of the amateurish c-programmer
guys.
You could even use it to attach some OSS real time "operating systems"
to
Linux.
At the Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano
(DIAPM) someone is thinking about using Cygnus ECOS, and RTEMS perhaps,
as the final real time server attached to rtai.c. I'm resisting the idea
only because I want to support my RTL variant, but it can be a very
smart and effective one.
The power of the approach is demonstrated by the easy porting of
NMT-RTLinux
fifos to rtai.c for UP-SMP applications, without touching the kernel,
while
allowing you to use any Linux task queue; instead of adding a new queue,
tq_rtl, that does nothing but what the slowest of the available queues,
tq_scheduler, already does.
It is also possible to use wake_up_interruptible directly. In this way
you'll discover that fifos are programmed very efficiently by Michael,
can be very fast and allow to avoid using shared memory, with a minor
efficiency loss but, bu with a far easier development work.
(On a dual PII 350, 64 MB RAM, a real time simulation of a control
application carries out 90Mflops, 45 on each cpu, at 1 Khz producing a
5MB/s log, that a front Linux process sends to a 5400 rpm disk, without
loosing bytes under mild forground load, just using the usual, but
modified, fifos; max jitter about 30 us).
It is believed that this approach is more flexible and should be the way
Linus-Linux goes to natively make hard real time available within the
standard distribution, istead of taking a lot of unneeded patching in
the basic Kernel.
It requires just a cleaner design of some functions and related
pointers, and it seems that 2.2.xx has already carried out a good great
leap forward along this direction. There is space for improvements
however.
After all nobody will ever forbid making available many different RTAI
modules within the official distribution, configurable with the usual
"make config".
Moreover the concept can be a template for easy porting of RTAIs to any
other architecture.
In fact most of the changes, from the basic interrupts handlers macros
upward, made to the Kernel by NMT-RTLinux are believed to be unedeed, we
change just about ten lines of the kernel while adding a few tens more,
without any visible performance degradation with respect to NMT-RTL.
It can be verified that most of the jitter and timing uncertainties do
not come from short interrupts disables, the longest one in rtai.c is
likely to be due to the mask_and_ack_8259, up to 4-5 us, while the
actual jitter can reach 30 us under heavy Linux foreground usage and is
mostly related to loss of cache coherency between interrupts. In fact a
heavy load implies a wider motion through the memory with consequent
cache misses.
That seems to be worse in full symmetric processing as, even if Linux
tries to schedule a process on a preferred cpu, under heavy load
processes
tend to continuously change the cpu on which they execute thus straining
the
cache more than on a UP. Another important factor seems to be the mother
board.
Our, maybe poor, experience seems to show that it is difficult to do
something better, as this is the real bottleneck in using PCs for high
frequency hard real time applications.
So be warned that even those commercial systems that claim a few
microsecs
max latency in practice cannot achieve it.
Clearly there is nothing new here, as the HAL concept is adopted by
Cygnus-ECOS and MS-NT which, even if Linuxers do not like the latter,
exploit a very good idea. I think that something similar can be found
also on Alphas Privileged Architecture Library code (PAL). Perhaps it is
not
strange that MS-NT has been a native OS for Alphas.
The plus of Linux is source code availability, that allows you to feel,
and
effectively be, the master of everything, so that you are fully
empowered
without depending upon anybody. Furthermore it is a lot of fun to crash
your
system, isn't it? (Someone think that it's pure madness at the highest
levels). .................................................
>
Ciao, Paolo.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
