|
在驱动程序层面，你肯定要把不规范的内嵌式RTOS代码转化为合适的驱动程序。如果你的旧应用程序已经很好被划分，或者使用RTOS I/O应用程序接口，或者分隔在不同的层面。你的工作把非常容易。如果特殊的I/O代码非常分散于整个你的旧应用程序，你会面临巨大无比的工作量了。
基于API的方法对于急于摆脱旧RTOS的开发者，或者尝试把原型综合在一起的人,更可能试图把很多RTOS API映射或者转化到Linux相当的位置。 程序体一般的接口几乎是透明的（兼容的API,IPC,系统数据类型等）。其余部分可以通过用#define 重新定义和使用宏来解决。剩下的部分需要重新编码，作为完整的抽象层的一部分。
通过使用仿真库－很多商业嵌入式Linux都带有（比如我们公司的针对Wind River VxWorks 和 pSOS的仿真库），或者使用第三方公司提供的API映射包，比如MapuSoft，能够使你在移植基于API的程序时有良好的开端。
移植RTOS代码和API 到Linux的多叉方法
大多数项目采用混合的方法，映射所有兼容的或者容易转化的API,重新配置那些对运行速度有要求的部分，和“像鼹鼠那样打洞”重新编码剩余的部分直到编译通过和运行。
在内核和用户空间能够适用的API对于急需重建和“更快又更脏”的API方法，你不得不重新分配RTOS应用程序和I/O代码以Linux内核和用户空的范例。
Linux分层次特权访问的结果是，通常仅仅内核代码（驱动程序）能够访问物理内存，其它的用户代码必须有根用户权限才能访问。
一般情况下，用户空间代码与Linux内核相隔离，只有当内核的出口信息出现在/proc/ksyms 时才能被它直接“看见”。更进一步讲，对于内核显示的系统调用不能够被直接调用，但是可以通过用户库调用。在Linux里面这种分隔是有意来加强稳定性和安全性。
相反的情况存在在写驱动程序的时候。静态链接的驱动程序专属于整个内核名字空间（不是出口），但是对于用户空间基于进程的符号和入口点完全不可见。并且，当你把驱动程序封装成可动态加载的模块时，你的程序在内核里面通过EXPORT_SYMBOL 宏使用显示的接口。
网络驱动程序移植
正如上面指出的，把字符和块驱动程序移植到Linux是直截了当的实践活动。移植网络驱动程序，要困难得多了回想Linux伴随TCP/IP一起成长，而大多数的RTOS 到90年代晚期才把网络考虑进去。即使如此，旧的网络存储常常仅有基本的功能，比如只能处理单个的会话或者同时只能访问一个端口，或者只能支持单一网络媒质的物理接口。在某些情况下网络结构，在允许多重接口和物理类型连接后，才能实现（比如Wind River VxWorks MUX代码）。坏消息是，你不得不重新写大部分或者全部的现成网络接口。好消息是，对于Linux重新划分不是太困难，而且有大量的开源网络设备驱动例子程序可供选择。
Linux 网络驱动程序框图
写网络驱动程序不是初学者的事，因为许多RTOS网络驱动程序实际上是从GPL的Linux接口程序演变而来，你也许通过代码本身发现程序易用性。更进一步讲，有大量的，并且一直在增长的系统集成和咨询社区，以合理的收费专注于帮助嵌入式开发者把他们的应用移植到Linux。
总结
这篇文章深入分析了，把整体软件从旧的RTOS转移到Linux过程中，嵌入式开发者面临的挑战和把得到的好处。寥寥2800字或者更多的内容对于深入研究许多驱动程序移植的细节来说太过于简单（总线接口的驱动程序API,地址转换等），但是丰富的现成的开源GPL驱动程序代码，可以作为你移植过程的文档和模板。本文作为导引肯定对你的团队在移植RTOS到Linux的时候有帮助，并为最佳适合于嵌入式Linux而重新规划代码有启发。
共3页: 上一页 [1] [2] 3 下一页
|
收藏
推荐
评论(0条)
