75 lines
3.6 KiB
HTML
75 lines
3.6 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>RTLinux HOWTO: Why RTLinux</TITLE>
|
|
<LINK HREF="RTLinux-HOWTO-4.html" REL=next>
|
|
<LINK HREF="RTLinux-HOWTO-2.html" REL=previous>
|
|
<LINK HREF="RTLinux-HOWTO.html#toc3" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="RTLinux-HOWTO-4.html">Next</A>
|
|
<A HREF="RTLinux-HOWTO-2.html">Previous</A>
|
|
<A HREF="RTLinux-HOWTO.html#toc3">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s3">3. Why RTLinux</A></H2>
|
|
|
|
<P>The reasons for the design of RTLinux can be understood by examining the
|
|
working of the standard Linux kernel. The Linux kernel separates the hardware
|
|
from the user-level tasks. The kernel uses scheduling algorithms and assigns
|
|
priority to each task for providing good average performances or throughput.
|
|
Thus the kernel has the ability to suspend any
|
|
user-level task, once that task has outrun the time-slice allotted to it
|
|
by the CPU. This scheduling algorithms along with device drivers,
|
|
uninterruptible system calls, the use of interrupt disabling and virtual
|
|
memory operations are sources of unpredictability. That is to say,
|
|
these sources cause hindrance to the realtime performance of a task.
|
|
<P>
|
|
<P>You might already be familiar with the non-realtime performance, say,
|
|
when you are listening to the music played using 'mpg123' or any other player.
|
|
After executing this process for
|
|
a pre-determined time-slice, the standard Linux kernel could preempt the
|
|
task and give the CPU to another one
|
|
(e.g. one that boots up the X server or Netscape). Consequently,
|
|
the continuity of the music is lost. Thus, in trying to ensure fair distribution of
|
|
CPU time among all processes, the kernel can prevent other events from
|
|
occurring.
|
|
<P>
|
|
<P>A realtime kernel should be able to guarantee the timing requirements of
|
|
the processes under it.
|
|
The RTLinux kernel accomplishes realtime performances by removing such
|
|
sources of unpredictability as discussed above. We can consider the RTLinux
|
|
kernel as sitting between the standard Linux kernel and the hardware. The
|
|
Linux kernel sees the realtime layer as the actual hardware. Now, the
|
|
user can both introduce and set priorities to each and every task. The user
|
|
can achieve correct timing for the processes by deciding on the
|
|
scheduling algorithms, priorities, frequency of execution etc. The
|
|
RTLinux kernel assigns lowest priority to the standard Linux kernel. Thus
|
|
the user-task will be executed in realtime.
|
|
<P>
|
|
<P>The actual realtime performance is obtained by intercepting all
|
|
hardware interrupts. Only for those interrupts that are related to
|
|
the RTLinux, the appropriate interrupt service routine is run. All other
|
|
interrupts are held and passed to the Linux kernel as software interrupts when
|
|
the RTLinux kernel is idle and then the standard Linux kernel runs. The RTLinux
|
|
executive is itself nonpreemptible.
|
|
<P>
|
|
<P>Realtime tasks are privileged (that is, they have direct access to hardware), and they
|
|
do not use virtual memory. Realtime tasks are written as special Linux
|
|
modules that can be dynamically loaded into memory. The
|
|
initialization code for a realtime tasks initializes the realtime task
|
|
structure and informs RTLinux kernel of its deadline,
|
|
period, and release-time constraints.
|
|
<P>
|
|
<P>RTLinux co-exists along with the Linux kernel since it leaves the Linux
|
|
kernel untouched. Via a set of relatively simple modifications,
|
|
it manages to convert the existing Linux kernel into a hard realtime environment
|
|
without hindering future Linux development.
|
|
<P>
|
|
<HR>
|
|
<A HREF="RTLinux-HOWTO-4.html">Next</A>
|
|
<A HREF="RTLinux-HOWTO-2.html">Previous</A>
|
|
<A HREF="RTLinux-HOWTO.html#toc3">Contents</A>
|
|
</BODY>
|
|
</HTML>
|