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

与在服务器和桌面系统的风风火火比较起来，Linux在嵌入式领域似乎总是不温不火，是生不逢时，还是另有隐情？

最近几年，Linux操作系统在桌面和服务器系统等领域的应用取得了很大的成功。它的存在已经对这些领域中的传统霸主，例如微软的Windows和Sun公司的SunOS/Solaris操作系统等造成了极大的威胁。这主要得益于其较低的使用开销和更高的应用性能：现在，Linux操作系统加高端奔腾处理器构成的计算机系统在性能上已经远远超过了同等价位的运行着Solaris的基于SPARC处理器的计算机系统;Linux能够取得成功的另一个主要原因在于它是一个开放源码的系统软件，Linux用户可以享受到世界各地Linux爱好者提供的支持。

就在Linux系统在桌面和服务器领域应用风头正劲的时候，业界内外普遍地认为Linux也会成功打入到嵌入式系统中，成为主流操作系统之一。但是，事与愿违，现实中的情形远没有那么乐观。那些为桌面和服务器系统提供Linux操作系统软件的开发商们并不热衷于将Linux引入到嵌入式系统领域。而其他的一些已经在嵌入式Linux领域开拓市场的公司，比如Lineo和MontaVista，也一直没有获得稳定的收益。为什么Linux没有能够在嵌入式领域中获得它在桌面系统中同样的辉煌呢？原因就是桌面系统和嵌入式系统对操作系统的需求有所差异。

桌面系统和嵌入式系统对操作系统的需求有很多差异，而且都很关键。我们在这里先讨论几个最重要的问题，这些问题已经足够体现出Linux系统在嵌入式系统领域所面临的挑战。这些挑战都是在之前的桌面系统应用中未曾遇到的，主要包括：

●中断延迟(interruptlatency）

●线程响应时间(threadresponsetime)

●调度策略（scheduling）

●设备驱动程序

●可靠性和安全性

以上这些都是技术层面上的挑战。而在将Linux系统引入嵌入式领域时，还有很多的非技术性层面上的挑战也是必须要考虑的。

技术挑战

中断延迟

实时系统（Real-TimeSystem）是指能够在限定的时间（一般是很短的时间范围）内对系统中发生的某类事件（比如从某个外围设备传来的中断请求）进行处理的系统。如果系统对这些事件的响应出现了问题，比如未能在限定时间内对其做出相应处理，就会导致系统出现故障。绝大多数嵌入式系统都有很高的实时性需求，而桌面系统却不一定。在嵌入式系统测试中，衡量系统实时性的最主要参数有两个：一个是中断延迟时间的长短，另一个是线程上下文切换时间的长短。

中断延迟是指从产生中断请求到相应中断服务程序的第一条指令被执行之间的这段时间。由于中断具备有优先级而且可以嵌套产生，因此可以测知优先级最高的中断在执行时的延迟时间。测试表明，产生中断延迟的原因除了处理器响应时间外，更重要的是操作系统往往会大大增加中断被延迟的时间。在操作系统运行过程中，存在着一些关键的操作。这些操作在执行时，操作系统会禁止在其间插入任何中断。因此如果一个中断请求在操作系统禁止中断的这段时间里产生，那么对它的处理就会始终保持在挂起状态，直到操作系统重新允许中断插入。最终，中断延迟在最坏情况下的数值是和操作系统关键操作中的指令序列在中断请求产生后继续执行的时间紧密相关。

实时系统就是要确保系统中的关键事件能够在限定的时间段内被处理。操作系统开发商会提供给用户一个表示中断延迟的数值以体现产品的实时性能。这个数值是在实验室环境下测得的，它可能是平均值，典型值，或者是在最好情况下的系统中断延迟。但在实际应用过程中，最坏情况下的延迟中断才是用户最需要考虑的。那么如何才能得到这个数值呢？瑞典的一个研究小组对操作系统中禁止中断产生的代码区域进行分析，试图用这种方法对当前一款商业化的实时操作系统进行研究并得到系统中最坏情况下的中断延迟的大小。

这项研究使用了先进的程序流分析方法来确定操作系统中所有的关键操作（即那些“禁止插入中断”的代码）区域的位置和结构。研究人员还利用了周期精确的模型来测定选定代码区域的被执行次数。但是研究结果并不让人感到振奋。因为用于禁止和允许中断的指令所需的源操作数在执行时才能确定，所以研究人员不能用静态分析的方法得到关键操作的执行情况。还有一些其他的程序流问题，比如关键操作序列的嵌套出现等等，也阻碍了研究的进展。最终据研究人员估测，大概只有一半数目的“禁止插入中断”的关键操作区域能够被确定，而另一半大约有600个区域会对中断响应时间产生未知的影响。

研究人员评估了他们能够确定的那些关键操作区域的执行时间。这些区域的执行