Linux操作系统的嵌入式领域面临新挑战

线程响应时间

线程响应时间是指从产生中断请求到由该中断服务程序唤起的线程中的第一条指令被执行之间的这段时间。和中断延迟一样，线程响应时间也是衡量系统实时性能的一个重要因素。嵌入式应用的设计者往往用线程实现程序所需的一些功能，比如设备操作代码，因为这样做便于进行调试而且会减少那些在执行过程中禁止插入中断的代码数量，有助于减少最坏情况下的中断延迟时间。

在线程的执行过程中，有一个重要的问题在于响应高优先级中断的线程的执行会受到其他低优先级中断的影响。在高优先级的线程执行过程中是允许插入中断的，因此可以有任意多的低优先级中断请求产生。这些低优先级中断请求的相关中断服务程序都要被依次执行，大大增加了线程响应时间。这是一个典型的“优先级翻转”的例子，即低优先级任务的执行延误了高优先级任务的工作。在桌面系统中，出现这样的翻转是无碍大局的。

实时操作系统应该能够提供一种方法来防止这种优先级翻转问题的出现。有一个简单却很有效的方法是由设计者在关键的中断处理线程中对中断的优先级加以区分。当某个线程被调度时，系统内核就限制住那些优先级比该线程低的中断产生。直到在没有更高优先级的线程要执行时，才重新允许插入低优先级的中断。

调度策略

Linux并没有提供和中断相关联的线程优先级。实时操作系统却需要进行基于线程优先级的调度，用来确保在某事件发生时，系统中的关键线程能够立即执行。

标准的Linux调度器使用的是“公平”的启发式调度策略。这主要是因为Linux继承了Unix的特性，是分时共享的交互式操作系统。因此，程序设计者就不可能指定一个具有绝对最高优先级的线程。当中断服务程序启动某个线程去处理相应事件时，Linux调度器很有可能会先选择一些其他的线程优先执行。也正因为如此，我们完全不可能确定在最坏情况下的线程响应时间。

与早些时候的v2.4内核相比，Linux的v2.6内核做了一些调度性能上的改进，但是对实时性的改造仍旧不在其中。按照Red Hat公司的说法：“线程库的实现几乎没有对实时性的支持。系统可以选用一些调度参数，但是这些参数往往是起不到任何作用的。出现这种情况的主要原因是内核中的大部分实现都不遵守实时性的规则……而且内核中的很多其他方面也没有能够给予提高实时性所需的必要支持。”

除去中断延迟时间较长以外，Linux运行时会发生在某一段时间内禁止抢占的现象，即使在v2.6内核中加入了“抢占补丁”后仍旧存在这个问题。有测试数据表明Linux的v2.6内核在最坏情况下的响应时间是1.2毫秒。这个数值虽然比2.4版本的20毫秒有了很大的提高，但是一个实时嵌入式操作系统在最坏情况下的响应时间最差也应该是在亚微秒这个量级上（需要依赖于具体的硬件配置），因此Linux相对于这个标准还有很大的差距。而且Linux系统中实测到的时间并不能反映出理论上的最坏情况，这一点在实时系统中是绝不允许的。

设备驱动程序

如果设备驱动代码运行在各自受保护的地址空间中，就会大大减少给系统带来的风险。现在，具有虚拟设备驱动结构的操作系统摒弃了传统的把设备驱动程序运行在内核物理存储空间的方法。在这种结构中，有些虚拟设备驱动由中断服务程序唤起，在内核空间以外对设备进行管理。还有些驱动采用的是非中断驱动的方式，直接在被映射到驱动进程内的设备相关的存储地址空间内进行操作。这种实现需要通过一套灵活、强大并且有效的API使得虚拟设备驱动能够安全地使用它所需的物理设备资源。

但是Linux系统缺乏这种虚拟设备驱动结构。虽然现在的Linux能够为应用提供受保护的虚拟存储空间，但是它还是把复杂的设备驱动程序加入到了自己的物理内核地址空间中执行，这就平添了很多风险。传统的增加新Linux设备驱动的方法是把这个驱动代码编译为目标文件，然后把其链接进内核中或者由内核模块装载器把它动态地装载。这些驱动程序很难被调试而且可以不受限制地访问任意物理存储空间。