Sparrow操作系统的回顾与总结
作者:网络转载 发布时间:[ 2014/1/6 13:48:18 ] 推荐标签:操作系统 Linux
到为止,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/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11