djyos的可移植性（一）

djyos

djyos的可移植性（一） [复制链接]

 

Djyos的可移植性

    提到可移植性，很多人会想到汇编，许多操作系统会把汇编行数看做可移植性的首要指标。其实，这又是一个误区。我们在谈论可移植性之前，还是要先弄清楚一个问题，即什么是可移植性！

    这也算问题吗？移植不就是把操作系统从一个硬件平台换到另一个硬件平台运行吗？

    这样理解，未免太片面了。

再次强调一下，硬件上只运行操作系统是没有任何意义的，产品的功能性能，必定要应用程序来实现。因此，可移植性也一样，应该强调的是应用程序的可移植性。一个硬件平台运行一个操作系统移植版本，但可能运行许多不同的应用程序，换一个硬件平台，需要移植的操作系统只有一份，但却有许多不同的应用程序代码需要移植。
    在为设计产品准备操作系统时，一般会参考一个已经移植好的操作系统，再根据项目硬件平台特征做少量的调整，只需要很少的工作。即使没有现成的移植可以参考，把操作系统移植到一个全新的硬件平台上，移植操作系统上的工作量，与应用程序的工作量比起来，还是只占极少的部分。对一个企业来说，硬件平台一般都会比较固定，操作系统只需要移植一次，经过充分测试后即可成为可靠的软件模块存档，切换产品时，一般更新配置即可。一次移植，终身使用，因此，即使在移植操作系统上的工作量增加一些，但这是一次性的工作，对一个企业或者开发团队来说，移植操作系统所花费的时间占总开发时间的比例很小。
    对于一个操作系统来说，大量的嵌入式最终产品才是最重要的，如果不应用于产品，操作系统本身毫无意义，产品也只有可靠的产品才有意义。产品的可靠性由可靠的应用程序和可靠的操作系统共同组成，应用程序的bug只会存在单个产品中，而操作系统的bug却是潜藏在所有产品中的定时炸弹，而且是最顽固的定时炸弹，因此，当可靠性与可移植性发生矛盾时，DJYOS系统优先保证可靠性。
   不要为了兼容更多的平台或者提高效率而使代码晦涩难懂，妨碍用户阅读，使用户难于充分掌握操作系统。过分地强调兼容性和代码效率，你可能需要用大量的#if来控制条件编译，使大量跟你的实际系统不相关的代码充斥在你的源码文件中，你还可能需要使用层层嵌套的宏定义，阅读时便需要层层展开，要看到代码的真是面目非常不容易。这真的很可怕，二战时美军训练印第安人充当通信兵，使用的全是明码语音通信，效率极高，译码的时间都省了，日本人虽然轻而易举地截获了电码，却如同天书一样无法破译。过多使用宏嵌套的代码就像印第安语电码一样，代码可以轻易得到，可读懂它就不是件容易的事情了。DJYOS系统约定，除了一些简单的类型定义外，包含代码的宏嵌套最多两级；条件编译嵌套最多两级，并且严格限制#if和#endif之间语句的行数。

我们还要看到，开发高可靠性的嵌入式产品，软件测试非常重要，把操作系统以及应用程序从一个CPU平台迁移到另一个CPU平台，需要做非常多的测试工作，测试的工作量远远多于修改程序文件的工作量。而测试的工作量又和软件中的bugs数量成比例的，bugs数量越多，则“测试——修改——再测试”的循环就越多。因此，DJYOS在考虑可移植性方面，主要着力于协助程序员减少跟移植相关的潜在的应用程序bugs数量。

软件的可移植性，应该是一个运行环境的概念，它是广义的，包括：

1、  cpu的指令集。

2、  编译器的算法。

3、  操作系统的参数。

4、  跟你一起运行的其他软件模块。

    例如，某产品由A、B、C、D四个模块组成，它的简化版本，由A、B、C三个模块组成，那么，对于A模块来说，它的运行环境，就有两种。一是有B、C、D三个模块组成，二是由B、C两个模块组成。

可移植性的优劣，有几个层次：

1、  无须任何修改，无须重新编译，直接适应新环境。

2、  需要重新编译才能适应新环境。

3、  需要修改配置、重新编译才能适应新环境。

4、  需要修改代码逻辑、重新编译才能适应新环境。

[ 本帖最后由 djyos 于 2012-8-13 12:53 编辑 ]