RTOS设备驱动向嵌人式Linux的移植

基于API的方法

对于急于摆脱旧RTOS，或者尝试把原型综合在一起的开发者, 更倾向于把很多RTOS映射或者转化为相当Linux API。程序的接口几乎是透明的（兼容的API,IPC,系统数据类型等）。其余部分可以通过用#define 重新定义和使用宏来解决。剩下的部分需要重新编码，作为完整抽象层的一部分。

通过使用仿真库－很多商业嵌入式Linux都带有（比如我们公司的针对Wind River VxWorks 和 pSOS的仿真库），或者使用第三方公司提供的API映射包，比如MapuSoft，能够使你在移植基于API的程序时有良好的开端。

大多数项目采用混合的方法，映射所有兼容的或者容易转化的API,重新配置那些对运行速度有要求的部分，重新编写剩余的部分代码直到编译通过和可以运行为止。

在内核和用户空间适用的API

对于需要重新编写和其他API实现方法，你得重新分配RTOS应用程序和I/O代码和Linux内核/用户空间相对应。

有两个非常重要的区别：

· RTOS平等地让应用程序和I/O代码能够访问任何地址，几乎可以进行任意操作， Linux则更讲究应用级别和权限。

· 旧的RTOS代码能够（至少在链接时）“看见”每一个符号和系统的入口点，Linux 用户代码是分离的，内核程序和用户程序完全分开。

Linux分层权限访问的结果是，仅内核代码（驱动程序）能够访问物理内存，其它用户代码必须有根用户权限才能访问。

一般情况下，用户空间代码与Linux内核相隔离，只有当内核的信息出现在/proc/ksyms 时才能被直接“看见”。进一步讲，不能直接调用对于内核可见的系统调用，只能通过用户库函数调用。Linux这种分隔是有意用来加强稳定性和安全性。

相反的当写驱动程序的时，静态链接的驱动程序专属于整个内核名字空间（不是出口），但是对于基于进程的用户空间，符号和入口点完全不可见。并且，当驱动程序封装成可动态加载的模块时，程序在内核里面通过EXPORT_SYMBOL 宏来使用显示的接口。