Sparrow操作系统的回顾与总结

发表于:2014-1-03 10:10

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:第二月    来源:51Testing软件测试网采编

  到今天为止,Sparrow操作系统的设计文档已经全部发布,代码也不准备继续更新了。在“自己写操作系统”这事儿完成之前,做一个总结。
  一个真正的操作系统没有“完成”的时候,但是Sparrow操作系统作为一个“习作”和个人的项目却可以在合适的时候说“完成”,因为它目标明确。最初设计Sparrow系统的目的就是学习Linux内核最基本最核心的部分,现在这个目的达到了。而Sparrow系统上虽然还有很多事情可以做,但是继续投入大量的时间去改造和完善就又与初衷不符了,我认为现在是合适的时刻结束了。
  回顾Sparrow
  现在回头再看Sparrow,仍然有一些让自己觉得遗憾的地方:
  没有驱动层。Linux的发展在很大程度上得力于它优秀的驱动程序机制,这个机制让Linux能广泛地支持各种设备。驱动程序的开发和驱动机制的进化也是Linux内核最活跃的一部分。Sparrow没有实现这个强大的机制,因为Sparrow使用的设备非常少,跟体系结构相关的特殊设备大概只有串口UART一种,所以就没有把这一块做得太复杂,只是做了一层薄薄的封装。
  支持的芯片少。现在Sparrow只支持S3C6410这一种CPU。其实最开始的计划是最终支持S3C2410、S3C2440和S3C6410三种,以S3C6410开始,完成之后再加入另两种芯片。这个过程会涉及到一些抽象和封装,所以将会是练习代码重构的好机会。这个计划后来取消有两个原因:一是后来认识到这三种芯片其实大同小异,没有很多重构的挑战,练习的意义不大,而对于其它的非ARM芯片,又没有太大兴趣;二是在开发Sparrow的这几年里面,我已经系统地学习了设计模式和重构方面的知识,这个练习已经显得太小了。
  宏内核与微内核。现在的Sparrow是宏内核,但最初我想把Sparrow设计成为一个可以在宏/微架构之间切换的系统,通过配置来选择构建成宏内核还是微内核。微内核方面的学习准备参考Minix系统。这个想法即使到现在我也仍然觉得有点意思,但最终放弃是因为现在我有了一些Linux内核知识作基础,再去学习Minix的微内核会容易一些,不需要再用“照着写一个”的办法了(老实说,这个办法的效率不算高)。
  项目管理。我把Sparrow做为自己经营的一个项目,曾一度在开发的过程中实践过项目管理的技巧。我使用的方法是Scrum,自己以一个星期为Sprint,在开始的时候做plan,并且breakdown成一个个小的task,还自己在小白板上画过burndown曲线。不过问题在于参与项目的人只有我一个,即使没有这个流程我仍然可以把过程管理好,不会有冲突发生,这个流程也就流于形式,所以最终废弃了。如果我从一开始就拉上几个朋友一起做的话,故事可能会不同。
  关于测试
  除了那些令人遗憾的地方,也有一些心得,我想特别说一下关于测试的事。
  Sparrow的单元测试比较充分,这是在一开始就决定的,其初衷是控制风险。内核技术是复杂的,多个“子系统”互相牵扯,而如果一些基础功能不稳定的话,在开发较高级的功能时出现问题就会很难解决。到那时我就得独自面对一团乱麻一样的问题,没有合作者,没有帮助,会浪费很多的时候,甚至让整个项目进展不下去。
  为了避免这样的风险,我在每开发完一项功能之后就马上设计单元测试(使用cUnit框架),现在几乎所有与体系结构无关的代码都有单元测试来保证质量。
  在Sparrow内核的各个子系统中,内存管理是最健全最稳定的一个。采用了页式存管,并划分出了用于系统启动期间使用的BootMem Allocator、实现Buddy算法的核心内存管理器Page Allocator以及高效的Slab Allocator这样三个层次。
  存管系统也是Sparrow内核最复杂的一部分,对它的测试算得上“苛刻”:在内存分配器测试中有这样一个用例,它不断地以随机大小来申请内存,直到内存耗尽,再以随机的顺序来释放所有这些内存,然后查看内存的状态是不是复原。然后再来一次。。。
  在测试中的确发现过一些藏得很深的问题,花了不少精力去debug。这样做是值得的,在后来的开发中,内存管理功能没有引起过任何麻烦,特别是在调试进程虚拟空间(栈和堆)的时候,可靠的内存管理让我得益不少。
  关于文档
  对于Sparrow的文档,我的期望是它能让读者对这个系统的设计“观其大略”,不必太深究细节,所以用了较多的图和较少的文字。如果您需要细节信息的话,不论文档怎么样你都还是会阅读源代码,而Sparrow的代码量并不大,很容易掌握,所以过细的文档在这里用处不大。
  比如《[Sparrow OS 设计文档连载(十一)] Tracing》那一章最后的环形缓冲区原理图,如果您在一睥之下能了解到环形缓冲区是一个封闭的区域,打印信息在里面循环更新的话,就已经获取到最有价值的信息了,细节可以到需要的时候再去关心。
  画图并不轻松,能让图示形象地表现出抽象的原理是很有挑战的。如果我的图片让您觉得不知所云的话,那完全是我的水平问题,请见谅。
  Sparrow的后续维护
  Sparrow的全部内容一直都稳定地托管在GitHub上面,它还将一直在那里:https://github.com/michael2012z/Sparrow
  同时我还会把所有的东西在我的个人网站上保存一份:http://www.2ndmoon.net/Sparrow/
  我在Github上面没有做任何权限方面的限制,也无所谓版权了,我非常愿意让它保存开放。如果您感兴趣,可以继续发展它。
  写在最后
  Sparrow即已完成,也就已经成为了过去,不应该为这一点成绩(其实算不得什么成绩)而沾沾自喜,如果再喋喋不休就更不好了。
  Sparrow操作系统的事就说到这里,但我对内核技术的学习还将继续。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号