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