如何构建操作系统内核开发团队
 

作者: 陆麟
转载请征得作者同意.
2018.4.25



最近闹得比较厉害的是ZTE的问题,网络上各路人士纷纷喊起缺芯片却操作系统.
芯片我是外行,但是因为本人有比较离奇的经验,亲自写过一个完整的Linux boot loader(基本每一行代码都是自己敲进去的),而且又碰巧为了加载OS, 又编写或整合了支持操作系统运行所必须的所有驱动.而且为了某个特定的SoC系统又完整地写了基本等价于PC机的BIOS的迷你版(代码规模上 很MINI),加之以前多年折腾Windows驱动,对操作系统,理解比大部分的开发人员来得深刻,写本文相对比较有把握。
本文不说写OS的各项细节,显然一个人去穷一生写一个大众认可的OS基本不怎么靠谱(写个嵌入式OS还是有可能的,但是一般我们大众认为缺少的OS显然 不是嵌入式OS),因此,本文所说的是在一个资深的系统开发人员眼中,怎么分工才能构建一个操作系统的开发团队。
以下,按写菜单的套路来写,力图让傻瓜领导都能看懂。这个团队不是用来写windows OS,也不是说写linux OS,团队结构与微软等实际写OS的事业部组织构成 完全不同,而是构建一个通用OS的开发组织。主要是内核团队的构建,而不是应用team构建。User mode的开发团队建制大众认知相对较多,只适合写八卦。

BootLoader team
- 这个团队的分工主要在于处理加载OS前与平台相关的基本工作。一般需要初始化CPU,IO控制器等,完成初始的内存布局映射,并且把OS加载到约定的位置后移交控制权。与Platform team及Device support team有部分人员可复用。其实一个BootLoader就是一个mini的OS。
OS Core team
- 这个团队需要细分为4-5个组,分别负责内存管理,进程管理,执行单元管理及调度,提供其他各组所需的基础服务功能(提供大家都要用的通用函数)。
Platform team
- 这个团队需要处理SMP架构,NUMA架构,主处理器+协处理器架构,对接各主流系统规范,比如UEFI,ACPI等。这些系统规范更多取决于硬件平台,领域知识相对要求高。并且是总体性能调优的主要责任团队。虚拟化本质上也是这个团队的责任范围。 比如在虚拟机里支持虚拟机等等。但是也会需要大批Device support team成员的交叉支持。
Device support team
- 这个团队是最庞大的一个队伍。细分为总线支持和设备支持2大组织。总线支持人数比设备支持少很多。设备支持团队,又需要细分为存储,输入设备,音频,电池,显示及输出,网络,各种可选的外挂类设备类型例如蓝牙,生物识别,无线电, 传感器等等等等。伴随新技术的出现,不停增加对各种设备的支持。
File system team
- 这个团队负责文件系统。那些已经遍地可见的介质使用的文件系统,例如FAT/CDFS/UFS等已经广泛使用,不支持肯定是不行的。更核心的是要负责结合OS自身的安全特性的文件系统。
Debugging support team
- 这个团队负责内核及用户模式调试相关模块及工作。
GUI support team
- 这个团队负责图形界面相关工作。
Network support team
- 这个团队规模可能仅次于Device Support Team。取决于对各项网络协议的支持。主要实现对各项协议处理。注意,不是网卡驱动的责任团队,网卡驱动是Device support team的事情。
Misc support team
- 这个团队负责支撑其他模块。从OS角度进行定义并提供例如通用的硬件故障识别接口,有限的自我容错支持等。提供ABI,比如POSIX,或自定义OS ABI集合,提供内核里面的加密解密库等。
上述团队,能分担相当多的实质工作。剩下的部分,需要有将这一切串接,让OS真正变成OS的灵魂。让代码在各处自由地流动。完成这项任务的到底是一个人还是一个团队,我本人觉得应该是个个体的人。一个OS,既是一个工程产物,更多是个艺术品。让一切变得鲜活的核心人员, 不是产品经理(我一直比较歧视产品经理这个角色:P),而是拥有最活跃思维的灵魂人物。比如David Culter,比如Linus。这个灵魂负责协调各个模块,定义各模块之间关键的接口,亲力亲为深入每一行代码并且使接口最终具有长久生命力。
剩下还有非常不关键,但是有比没好的团队是文档团队。一个OS的0.1时代,正常情况下是没有文档的。不要被工程化所欺骗。工程化的文档都是后补的。如果前期写完,那肯定被反复修改或者脱离实际实现。做到最优也就是边做边写。:P

好了,写到这里暂时收笔。