实时 *** 作系统到Linux系统的移植

　　从一个 *** 作系统到另一个 *** 作系统应用程序的移植即使在最好的情况下也经常是一个艰巨的任务。把一个实时的嵌入式应用程序移植到一个新的 *** 作系统上可以说是一项最困难的任务。

　　为了帮助开发人员计划在不久的将来转移到嵌入式Linux上，或者考虑将现有的应用程序运行在嵌入式Linux上这种投资的必要性，Jim 解释了这一转换的过程，评估了涉及到的困难和挑战，并且阐述了认识这种转换的益处。

　　越来越多的公司正在转向嵌入式Linux，把它作为他们下一代产品的 *** 作系统。然而他们以前都是使用实时 *** 作系统作为他们的嵌入式系统。事实上，VDC的报告显示了嵌入式Linux可以占到32位和64位领域设计的三分之一，是其他所有嵌入式系统的两倍。

　　很明显，关于从老式RTOS产品的应用程序移植到Linux的可行性的问题必须得到回答，由此这种移植才能够被有效的用于工程管理。

　　一个典型的基于RTOS的应用程序依赖于很多因素,其中最重要的是编程/内存模型、API、性能、特别是实时响应的能力。另外一个重要的考虑是软件开发环境，但那是软件环境文章值得讨论的话题。

　　编程模型

　　几乎所有使用的RTOS有一个简单的编程模型，它由多线程的执行(通常称为任务)构成，包含在单一的地址空间中。举例来说，一个c语言的程序有一个单一的主函数,它创建所有其他的线程。每一个线程依次被定义为总程序中的一个c函数。典型的，不管是RTOS还是非保护内存中的应用程序，他们的物理地址和逻辑地址都是一样的。可能会有一些超级用户模式下的 *** 作使用限制了在用户模式下的应用程序发出一些指令。基本上，所有的内存对于应用程序来说是虚拟的。

　　在过去，大多数嵌入式处理器没有内存管理单元，因此RTOS单地址空间模式是必须的。然而今天大多数的中高端处理器配备了MMU，因此如果需要的话，MMU能够管理内存。

　　该体系结构的描述提出了一个移植RTOS代码到Linux上的简单架构。

　　RTOS的全部应用代码移植到一个Linux单进程

　　RTOS的任务转换成Linux线程

　　RTOS的物理地址空间映射到Linux的虚拟地址空间

　　诸如VME机架的多板或多处理器架构，移植到一个多进程的Linux应用。

　　构架上的考虑：进程和线程的创建

　　是否使用遵循API的VXWORKS和PSOS等RTOS仿真软件包，开发人员最终必须决定是否将线程或是进程作为执行RTOS的任务。在这点上，Linux内核对待不管是线程还是进程都是同等的，都是以调度为目的。然而不同的API创建和管理每个实体的类型、性能、资源的成本和益处都是关联的。

　　通常来说，进程比线程大一点，因为他们传送着更多的上下文信息。一个Linux线程的上下文如同RTOS的一个任务，主要由cpu寄存器、堆栈、当前的程序指针以及一些内核数据结构的入口组成。一个进程加上一个完整的虚拟地址空间。这样，至少内核必须创建和跟踪进程的页转换、所有代码的类型、上下文、数据等。对于重量级进程上下文的主要影响有两点:创建的时间和相互的上下文切换时间。

　　只要可能，RTOS的代码都会争取要轻量级的执行。同样的，当很多RTOS提供了动态的任务创建API,其他以静态任务定义页表为特色，所有RTOS的商家不鼓励使用频繁的任务创建以节省时间和空间。Linux进程的创建不是故意那么麻烦;Linux进程是重量级的，因为他们提供了更多的保护性和依赖性。

　　这个熟悉地老式的架构，因为简单，所以非常容易遭受破坏。正在运行的任务能够覆盖应用程序的代码和数据，另外还会写入到外围设备的寄存器、破坏内核的数据结构、覆盖内核代码。任务的堆栈能够很容易的溢出，并且一个接一个被覆盖掉或者通过控制内存来破坏堆的顶部、其他数据或者附近的代码。

　　更高的层次来说，这种非正式有组织的，高度非遮掩的架构提出了对于代码质量的两个主要挑战：自身的失败机会以及和主要事件再次失败的结合。

　　当个别任务或者其他软件组件失败了，它失败的原因几乎不可能被定位。甚至当检测到失败并且尝试恢复时候会以整个系统的失败而结束。监视代码不能够经常安全地重启任务，RTOS不能够恢复由失败任务动态定位的资源。结果就是复位通常是通过强制使用看门狗定时器来完成的，看门狗定时器重新启动整个系统或者软件引起的系统错误。

　　通常当一个程序跑飞了，它没有任何征兆。一个错误的任务能够破坏在RTOS系统中任何地方的数据和代码。幸运的是，虽然这些破坏的影响瞬间产生，但是好像破坏的影响会在几秒、几小时、几个月以后才会出现。

　　当异常的征兆出现了，去联想预想不到的应用程序行为是及其困难的，这些行为由于原始的原因或者是很微小的，或者是破坏性的。