preface.tex

rtai-3.1-test3的源代码(Real-Time Application Interface )

\chapter{Preface}
\label{chap:preface}

% ----------------------------------------------------------------------------

\section{About this Guide}
\label{sec:preface:about}

RTAI has become one of the most sophisticated frameworks for Hard
Realtime (HRT) on Linux. But what's the best way to use it for \emph{your}
application? Until now there was no "unified" documentation for RTAI which 
could be used as a tutorial to learn how RTAI works \emph{and} as a
reference for all the different sub packets and functions the framework
provides. 

The \emph{RTAI 3.0 Reference Guide} tries to solve this problem. It is
an attempt to unify all the existing documentation of the RTAI project,
which, until now, existed in several places like the sourcecode, the web
site, some READMEs and other locations.

% ----------------------------------------------------------------------------

\section{RTAI History}
\label{sec:preface:hist}

\textbf{(FIXME: add earlier RTAI history here)}

During all this time the policy of the maintainers was to add almost
every piece of contributed code to the RTAI packet, because the idea was 
that if something was useful for somebody it could be useful for somebody 
else as well. RTAI was organized after the Bazaar development model described 
by Eric Raymond \cite{Raymond:CatBazaar}. Although this model worked quite fine 
for several years it turned out over the time that this model resulted in lots 
of features existing in several, incompatible implementations which where 
\emph{almost} identical but not really. And, after all, the "organic grow" 
of the code resulted in large pieces of code which were less and less 
maintainable and could not easily be separated into independend modules.
It turned out that in the future, user space hard realtime would more
and more replace the traditional design of HRT in kernel modules in
combination with userland tools for the handling of non-realtime tasks.
This trend was followed with with the LXRT, LXRT-Informed and New-LXRT
implementations of userspace realtime, but it was clear that the future 
could only be based on a better structured code base. 

On the Hardware Abstraction Layer, the lowlevel interface between the
hardware and the basic interrupt mechanisms of RTAI, "RTHAL" was used
for most of the time. The RTHAL mechanism was basically the same
technique which was used by RT-Linux: a deferred interrupt scheme.
Although the mechanism worked quite fine it was a target of large and
unfruitful discussions, triggered by the infamouse RT-Linux patent,
filed by Victor Yodaiken in 1997 \cite{LinuxDevices:InfamousPatent}. To
end these contraproductive discussions and to base RTAI on a more
flexible technology Karim Yaghmour published an article about "ADEOS -
Adaptive Domains for Operating Systems" in 2000 (? FIXME) in which he
described a technology which could be used for more than hard realtime.
Using a technology which is used by \emph{more} people is generally a
Good Thing (TM), because the more people use a piece of code the better
it's quality would be. As ADEOS could also be used to make several
instances of Linux run on a machine at the same time, or to make
glueless kernel debuggers, it was considered to be a candidate for the
hardware abstraction layer of the Next Generation RTAI. And, last but
not least, as the technology used by ADEOS is known and published for
quite a long term this would finally end the uggly patent discussion
with all it's fear, uncertaincy and doubt. 

In 2002 the RTAI team started to think about a large redesign to make
RTAI fit for the "Next Generation" of realtime software. It all started
with Philippe Gerum implementing the ADEOS technology described by Karim
Yaghmour. The next move was that the existing code base of RTAI was
split into several logical units which could be maintained as
independend packets. Until now, people had to install the whole RTAI
packet, no matter if they needed everything or not. It was difficult to
find out how things worked together and it was difficult for people to
find their way into the RTAI development team. All this should become
better and easier with the next major release. Philippe Gerum started to
reorganize the RTAI tree with help of the development team. At the end
of 2003 the first release of the "new" RTAI was released.  

% ----------------------------------------------------------------------------

\section{Participating in the RTAI Team}
\label{sec:preface:participating}

RTAI has always been a community effort, and this will not change with
the "new" RTAI. Although we try to put a better "structural design"
behind the software the team still follows Paolo Mangegazza's idea of
a community effort. Things that are useful for somebody will still
find it's way into the package, although the maintainers try to make
the "big plan" behind RTAI more visible to the outside.

It is most important that people do not only \emph{work} with RTAI but
\emph{actively participate} in the RTAI development team. It is easier
than ever to do this today: the "RTAI-Dev" mailing list was opened up
for the general public so that everybody can see what the developers are
doing and how RTAI continues evolving. Who is interested in joining the
team can simply subscribe the RTAI-Dev mailing list and help making
RTAI+Linux the best realtime operating system which ever existed. One of
the most important properties of the RTAI team is that it is a team~--
people try to achieve a goal by working together. It always has been fun
for the team members to develop RTAI in a cooperative and constructive
way, and we hope that this will not change in the near future.

People who want to participate in the RTAI development should first
subscribe the mailing lists. Further details can be found on the
website.