Embedded 版 (精华区)

发信人: Zinux (Linux技工), 信区: Embedded_system
标  题: Real-Time Linux 简介
发信站: 哈工大紫丁香 (2001年10月26日18:28:04 星期五), 站内信件


Real-Time Linux 简介
2001-08-02 嵌入式Linux 报道

------------------------------------------------------------------------
-----
---


    即时作业系统 (Real-time OS) 是相对于分时作业系统 (Time-Sharing OS) 
的一个
 概念。在一个分时作业系统中，电脑系统的资料会被平均的分配给系统内所有的
工 作
。对于这些工作而言，它们似乎是在一个速度较慢、资源较少的虚拟系统上工作。
 而这
个虚拟系统所拥有的资源会和真实系统内等待执行的工作数有关。简单的说，如 
果有
n 个工作要做，每一个工作就会分到 n 分之一的资源。

    然而在一个即时作业系统之中，系统内有多少工作并不是那么重要。我们关心
的 事
一个工作在多少的时间内可以被完成。和分时作业系统最大的不同之处在于 『时
限(dea
dline)』这个概念，即时作业系统通常会要求每一个工作在交付给系 统的时候同
时也给
定一个时限。即时作业系统的任务不只是要求完成每一个工作， 并且要按时给定
的时限
完成每一个工作。


    所以我们可以看出这二个概念的不同之处，分时作业系统的重点在于『公平』
， 而
即时作业系统的重点在于『时限(timing constraint))』。
    任何时候。我不是开玩笑，当一个即时作业系统中的每一个工作都有相同的时
限时
， 它应该和分时作业系统用相同的方式工作。分时作业系统和即时作业系统的分
野在于
 工作的特性而非作业系统工作的模式。

    在很多的书及文献上我们可能会看到『硬即时(hard real-time)』和『软即时
 (
soft real-time)』这二个名词。不同的人会给它们不同的意义，但大致来说它们
 是一
组相对的概念。硬即时对满足时限的要求会比软即时来的严格。有些人会从 工作
的特性
上来分，硬即时工作 (hard real-time task) 通常指不能有任何差 错的工作而软
即时
则是指比较容许差错的工作。例如我们常会用核能电厂和看 VCD 为例，用在核能
电厂的
即时作业系统如果出了差错可能会导致严重的损害，然而 VCD Player 出了些差错
不过
是让使用者认清他所用的程式不够好而已。所以前者 是硬即时，后者是软即时。


    但在大多数的状况下，分野并不是如此的清楚。做 VCD Player 的厂商当然不
 希望
它的 Player 老是出错，它也会希望 Player 用一个硬即时作业系统来驱动。 所
以硬即
时和软即时的差别可能只是分类学上的问题而已。

    然而对于一般的应用而言，即时作业系统的意义在那里呢? 我们使用流览器看
一 个
网站时，如果结果在 0.5 秒内出现，我们可能会觉得非常舒服。如果结果在 2 秒
才出
现，可能会觉得有些延迟。但如果花上 30 秒才出现，那可能就没有人会等 到结
果出现
了。
了。

    对于我们而言，等个 3,5 秒可能觉得没什么。但也许 Bill Gates 不这么想
， 他
会算给你听他的一秒值多少钱! 所以不同的人可能会对延迟有不同的看法。即 时
作业系
统最大的优势就在于他可以为不同的工作提供『不同等级的服务( 
differentiated
service)』。

    一个对即时系统常有的误解是即时系统是一个高效率 (high performance) 的
 系统
，它会跑得比一般作业系统来的快，overhead 来得小。这其实是市场策略宣 传造
成的
影响。一大堆非常小的作业系统宣称它们是嵌入式即时作业系统 (embedded
real-time OS)，这么一来『嵌入』、『即时』和『小』就被莫名其 妙的连起来了
。实
事上这三个是完全不相干的概念。『嵌入』指的是作业系统可 以在一些资源受限
的环境
，例如没有 disk，的情况下工作。『小』是指因为功能 简单，要求不多，所以作
业系
统可以写的很小，减少不必要的额外负担。这些都 和『即时』的概念完全没有关
系。不
幸的是，即使是学有专精的电脑工程师也常 把它们混为一谈。

    为什么不用? 即时作业系统和分时作业系统并不是完全互斥的概念，我前面说
过如
果一个即时作业系统中所有的工作都有相同的时限，那它应该会制造出和分时作业
 系统
相同的结果。

    所以一个系统可以同时执行分时和即时的工作另一个常有的误解是即时的工作
 应该
比分时的工作先执行。这其实是不对的，即时的工作只是要求在时限内完成 而已
，一个
时限在 10 秒之后的工作没有道理一定要在现在立刻执行。太早完成 它没有任何
好处，
时限在 10 秒之后的工作没有道理一定要在现在立刻执行。太早完成 它没有任何
好处，
有时还会造成系统不必要的负担。

    即时作业系统的优势在于它知道目前系统资源使用的状况，它能比起分时作业
 系统
更精准的控制系统资源的使用。对于分时作业系统而言，它无法预测一个工 作到
底还须
要花多少时间才能完成。因此对于比较重要的工作，唯一的方法就是 尽快的完成
它。而
即时作业系统可以预测工作完成的时间，因此它可以轻易的决 定工作要在什么时
间被执
行。

    所以即时作业系统所做的事，不过就是一个更强大的 renice 指令而已。在
renice 中，你只能指定一个叫优先权 (priority) 的值。优先权越高的工作 在分
时系
统中会分到更多的时间，但多多少呢? 没人能回答这个问题，因为在 分时作业系
统中不
把它视为一个重要的事。

    而即时作业系统的 renice 指定可以指定一大堆的参数，你可以指定前述的 
时限
(deadline)，优先权 (priority)。还可以指定工作在单工状态下执行所 需的时间

(execution time)、工作应该在什么时候允许开始执行 (start time) 、什么时候
就不
应该再继续下去了(finish time)。当然过去二十年来在即时作 业系统理论上的发
展使
得我们还有更多更多的可能性来实作即时作业系统的 renice 指令。但简单的说，
我们
得到的是一个更强大的 renice 指令。它可以被用来更 精准的调整系统的整体效
能。这
也就是我为什么会认为，为什么不用即时作业系 统。

    我的看法是，在将来的作业系统，即时会是一个和网路一样、是系统标准的功
能。
    我的看法是，在将来的作业系统，即时会是一个和网路一样、是系统标准的功
能。


    和 Linux 其它领域一般，有一大堆的人都试图为 Linux 加上即时的功能。每
个人
都有不同的看法，每个人看的角度也不相同，所以产生了各式各样的『
real-time
Linux OS』。在这里，我们看到了开放原始码 (open source) 在这个领域优势所
 在。
我们可以想见在不久的将来，这些各有专精的系统会自然的合并成一套非常好 用
的即时
作业系统。而不是相互用市场的策略恶性竞争。所以 open source 可以 提供我们
一套
更新、更好、更实用的即时作业系统。

    接下来，我们先简介一下现存的各种 real-time Linux OS。

NMT RT-Linux
    NMT 是新墨西哥科技大学(New Mexico Technology) 的缩写。这一套系统可以
说是
所有 Real-time Linux 的鼻祖。它目前已经发展到 3.0 版。这个系统是由 
Victor
Yodaiken 和它的学生 Michael Barabanov 所完成。这个系统的概念是『架空』
Linux kernel，使得它的 real-time 行程得以尽快的被执行。下面的图例说明了
 NMT
RT-Linux 和其它类似产品的系统架构。

    你可以看到基本上RT-Linux 中的即时工作(realtime task) 其实并不是 一个

Linux 的行程，而是一个 Linux 的可载入式核心模组( loadable kernel 
module)。



    之所以要如此做的原因在于 Linux 是一个很大的系统，且在设计的时候并没
 有考
虑 real-time 的需求。举个例说，单一个 Linux 系统呼叫可能会花上超过 
10ms 的时
间。对有些像工业控制的应用而言，它们对时间的要求通常在 1ms 的 等级上，
Linux
根本无法满足这种需求。所以 NMT RT-Linux 采用一个比较简单 的做法，它乾脆
不用直
接 Linux 的任何功能，而把需要高度时间精确度的工作 写成一个驱动程式的型式
，然
后直接用 PC 时序晶片 (timer chip) 所产生的中 断呼叫这个驱动程式。如此一
来，不
管 Linux 系统呼叫的时间有多长都没有关系 了。

    从这个角度看，NMT RT-Linux 其实是一个即时驱动程式的架构，算不上是真
 正的
real-time Linux. 但由于它出现的早，且其架构很符合自动控制的需求。 使用者
非常
的多，且多半是有关自动控制的应用。

RTAI
    RTAI 是 Real-Time Application Interface 的缩写。顾名思义知道它是一套
可 以
用来写即时应用程式的界面。大致而言，RTAI 和 NMT RT-Linux 是相同的东西。
 它同
样的架空了 Linux，而直接用可载入式核心模组( loadable kernel module) 实作

real-time process。每一个即时行程实际上就是一个可载入式核心模组。

    RTAI 和 NMT RT-Linux 最大的不同地方在于它非常小心的在 Linux 上定义了
 一组
 RTHAL (Real-Time Hardware Abstraction Layer)。RTHAL 将 RTAI 需要 在 
Linux 中
修改的部份定义成一组程式界面，RTAI 只使用这组界面和 Linux 沟通。这样做的
好处
在于我们可以将直接修改 Linux 核心的程式码减至最小， 这使得将 RTHAL 移植
到新版
在于我们可以将直接修改 Linux 核心的程式码减至最小， 这使得将 RTHAL 移植
到新版
 Linux 的工作量减至最低。

    RTAI 采取这种途径最大的原因在于 NMT RT-Linux 在由 2.0 版移植至 2.2 
版 的
过程式遇到问题，使得基于 2.2 版核心的 NMT RT-Linux 一直无法完成。所以 在

Dipartimento di Ingegneria Aerospaziale Politecnico di Milano 的 Paolo
Mantegazza 和他的同事们就决定自行做移植的工作，但由 NMT RT-Linux 的困境
他们体
认到必须采取上述的途径以解决将来可能再度面临的相容性问题。

    于是 RTAI 便诞生了，它是一个比 NMT RT-Linux 更好的 NMT RT-Linux，虽
 然后
来 NMT RT-Linux 也随后完成移植的工作，但那已经是 RTAI 诞生半年以 后的事
了。

LXRT
    由于 RTAI 无法直接使用 Linux 的系统呼叫，解决的方法是使用 RT-FIFO 将
一个
RTAI real-time kernel module 和真正的 Linux 行程连接在一起，由这个行程做
 代理
人的工作为其呼叫 Linux 系统呼叫。下图说明了 LXRT proxy 行程的概念



    红色的部份表示一组 RTAI 的即时行程和它在使用者模式 (user space) 的 
伙伴。
你可以了解，当 proxy 启动后，它不再可以被任何的抢先 (preempt)， 所以原本
有的
优势就不再保有了。


KURT
    KURT 是由 kansas 大学所创造的系统，它和 NMT RT-Linux 及 RTAI 有很大
的不同
。KURT 是第一个可以使用系统呼叫的 real-time Linux。由于 KURT只是简单的将

Linux 的排程器用一个很简单的时间驱动式(time driven)排程器加以取代，即时
行程的
执行很容易很其它非即时行程的影响。

RED-Linux
    这是小弟在下不才我在加州大学 Irvine 分校所做的系统，它和 KURT 类似，
是一
个 可以使用所以 Linux 系统呼叫的 real-time Linux。它的特点是使用『抢先检
查点
(preemption point)』改善系统的反应速度。前面说过 KURT 的最大问题在于它受
 限于
原有的 Linux 架构，使得系统的反应时间很难控制。然而在 RED-Linux 这一 点
已经被
大大的改善，由在 2.0 版的经验得知其反应延迟约在 100 us 左右。

    RED-Linux 非常有弹性的排程器架构也是其特点之一，这部份基本上就是我博
士 论
文的主轴。它使得 RED-Linux 可以符合各种不同复杂度系统的需求。基本上，它
将排程
器分成 dispartcher 和 allocator 二部份，dispatcher 在核心中执行而 
allocator
在使用者模式执行。allocator 可以是应用程式的一部份，也可以是一个独立的单
位。
通常它可能是 middleware 的一部份，负责将应用程式的 resource request 转换
成
kerner 可以了解的格式。

    RED-Linux 目前正在进行 POSIX 相容模式的移植工作，所有 POSIX 中的即时
 排程
、计时器、sporadic server 等都将会被实作出来。
、计时器、sporadic server 等都将会被实作出来。

    所有这些有关 real-time Linux 的计画都是在 open source 的情况下发展，
所以
我们可以预期在将来它们会有某些程度上截长补短的情况出现。前面说过，
real-time
Linux 主要有二个大类。第一种是 NMT RT-Linux 和 RTAI，它们的即时行程实际
上 是
一个核心模组。所以它们事实上是一种 real-time 驱动程式，RTAI 和档案系统 
及网路
系统其实有很相似的结构，差别只是在于其驱动的硬体类别不同而已。

    而另一方面，如 KURT, Linux/RK 及 RED-Linux 之类的系统则受限于能达到
的时
间解析度。虽然 RED-Linux 已经把这个极限推到 1ms 左右，但我们可以预期在 
PC 的
架构下要达到 100us 以下是很困难的。也就是说，对于要求 10K 以上频率的应用
 是不
可能使用这种架构来达成。

    但这其实是一个很合理的限制，我们可以将二种架构整合成一个系统来满足 
所有的
需求。LXRT 是一个正确的方向，但如果使用 RED-Linux 和 RTAI 整合 可能更能
达成需
求。RED-Linux 非常弹性的排程器架构使得整合更行简单。我 希望能在未来半年
内推出
这个产品，以成为一个终极的 real-time Linux。并 思考如何使整个系统正式的
和
Linux 整合以利未来的发展。




本文出处：【LinuxFAB】
间解析度。虽然 RED-Linux 已经把这个极限推到 1ms 左右，但我们可以预期在 
PC 的

--

  puke! 
  技工而已

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