djyos的可移植性（六）
4. 泛设备模型，解决移植问题与传统操作系统的设备驱动架构不同，djyos的设备驱动程序被赋予了更广泛的含义，它是被设计成功能模块间互相访问的接口，功能模块可能是硬件，也可能是软件，还可能是软硬件结合的模块，驱动程序不再仅仅是访问硬件的接口。从软硬件联合设计的角度，DJYOS系统并不区分软件模块还是硬件模块，如果完整产品由多个模块组成，任意一个模块在别的模块“眼里”都可以以设备的形式出现的，使用设备的模块并不知道该设备的实现细节，也不知道该设备是由硬件组成的还是由纯软件组成的。某一个功能由软件实现还是硬件实现并不重要，关键的是，它实现了需要的功能，并且为别的模块提供了相同的访问和操作接口。
在软件开发领域，我们还会碰到以下2种尴尬：
1. 许多企业起步时往往都没有什么编程规范，软件一般由几个高水平的天才完成，往往是软件实现技巧非常高明，但由于缺乏规范和标准，但软件的接口往往不好。当企业发展壮大后，软件开发就会规范化，这些早期软件就显得有些非驴非马了。它一方面是老一代程序员的心血结晶，而且确实有很大的价值；另一方面，它又很难与新软件配合使用。把他们作为包袱背上吧，软件的规范性就会受到破坏，让系统很别扭；如果舍弃这些代码，实在有些可惜。
2. 很多企业开发产品时会利用开源代码或者购买商业化的中间件来加快产品开发，也确实有许多开源代码是非常优秀的，许多开源代码有一些组织在维护并不断升级。但是这些代码的书写格式以及编程规范往往与企业的规范和程序员的习惯不一致，如果直接与公司的其他代码揉在一起，势必会破坏代码的一致性，轻则导致书写风格的不统一，重则会使代码的接口规范遭到破坏，使其他代码削足适履地迎合这些开源代码。重写这些代码以使其符合规范也是不明智的，因为重写会导致潜伏bug，而且不能享受开源代码维护者升级的好处。
上述问题，归根到底，是可移植性问题，就把旧的、不规范的软件整体移植到新的软件环境中的问题。
在DJYOS操作系统中，利用泛设备驱动程序概念，很好地解决了上述问题。只要把这些“老”程序和开源程序统称为外来程序，象对待硬件模块一样，做个driver把这些模块封装起来，把这些外来程序当作设备来访问，其他模块就可以用标准的符合规范的方法访问这些“老”代码了。当然，软件模块之间使用driver，效率会有所降低，但当今电子技术的发展，一个产品中计算部分所占的成本已经越来越低了，提高运算系统的速度只需增加很少的成本，甚至有许多嵌入式系统根本就没有充分利用cpu的计算能力。 顶，，占个沙发 顶板凳~~~~~~~~~ 最近在研究操作系统，什么时候有空跟大侠讨教一二，：） 随时恭候啊，可以QQ我：531707437 虽然不懂！还是要顶下
页:
[1]