Embedded 版 (精华区)

发信人: vmlinuz (生活将因为你而美丽), 信区: Embedded_system
标  题: Linux as an Embedded Operating System (5)
发信站: 哈工大紫丁香 (2001年06月01日08:39:53 星期五), 转信

Implementing data streaming systems appears to have been the primary
motivation of the RT-Linux designers. But the FIFO scheme provides a pretty
good way of implementing semaphores. A binary semaphore can be implemented
by creating a FIFO of size one. The "give" operation (also known as "V" or
"signal") is then simply an rtf_put() of size one, with the content of the
data insignificant and the error return ignored. The "take" operation (or
"P" or "wait") is an rtf_get() with size one. A counting semaphore can be
implemented simply by creating the FIFO with a size large enough to
accommodate the expected number of "give" operations. So the FIFO
mechanism provides most of the functionality needed for task synchronization
in real-time applications. The current implementation lacks some
functionality to which RTOS users are accustomed, such as priority
inheritance (to prevent priority inversion) and task deletion safety.
But careful design can almost always prevent the problems these features
are intended to address. In addition, although the FIFO operations can
be set up to block when data is not available (when reading the FIFO) or
when space is not available (when writing), the syntax for doing so is
rather cumbersome, as blocking capability appears not to have been
a priority of the designers. Nevertheless, at least one effort is under way
to provide an easy syntax for blocking operations on FIFOs.6 This effort
also implements timeouts when blocking, an important feature in many
embedded applications. The simple, open design of RT-Linux allows users
to implement such additional favorite features quite easily.
An interesting aspect of RT-Linux is the way by which the designers made
the Linux kernel preemptable. Linux, like most Unix-type operating systems,
has a kernel that disables interrupts for long periods of time. This is,
of course, exactly what makes Linux a non-real-time OS. Two approaches to
solving this problem might be taken. The first is to redesign the kernel
so that it can be preempted. But the Linux kernel is big, complex, and
subject to frequent modification. It was designed by programmers with
little interest in real-time applications in mind. Thus, imposing a real-
time mindset onto the existing code would be impractical. And even if done
once, the modifications would have to be reexamined and redone every time a
new version of Linux was released-also impractical. The RT-Linux designers
instead took a different approach to making Linux preemptable. They divide
the interrupts into two groups: those under the control of Linux, and those
controlled by RT-Linux. RT-Linux interrupts, like RT-Linux tasks, are
restricted in what they can do; they cannot make Linux calls. So there
is no reason that they can't interrupt the Linux kernel. After all,
they can't interfere with anything in the kernel if they don't change
anything in it. On the other hand, Linux interrupts can't be allowed
to interrupt the kernel. So RT-Linux implements a virtual interrupt scheme
in which Linux itself is never allowed to disable interrupts. Linux uses
"cli" and "sti" macros to implement disabling and enabling interrupts. In
standard Linux, these macros simply execute the corresponding x86
instructions. RT-Linux modifies these macros so that instead of disabling
interrupts when a "cli" is executed, it simply reroutes the interrupt to
some RT-Linux code. If the interrupt is an RT-Linux interrupt, it is
allowed to continue. If it is a Linux interrupt, a flag is set. When a
"sti" is executed, any pending Linux interrupts are executed. In
this way, Linux still can't interrupt itself, but RT-Linux can interrupt it.
(TO BE CONTINUED)

--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: mtlab4.hit.edu.cn]