转自嵌入式版：友好组与软件项目团队组织

djyos

从一个例子谈起，笔者曾经有一个项目需要做一个在 Linux 下的PCI 卡驱动程序，由于对 Linux不熟悉，所以花了大量时间熟悉 Linux 系统内核（我只是要写一个 driver，却要熟悉整个内核），在调试的时候，由于驱动程序运行在内核空间，驱动程序特别是中断里面的 bugs 造成反复的重启系统，而且这类错误往往无从着手查，因为系统崩溃了是不会给你输出任何信息的，只能重启，反复的重启差点没把我搞得精神分裂。这时候我就想，如果用户编写的 linux 设备驱动程序运行在用户空间，我根本不用花那么多时间和精力去熟悉 Linux 内核，也不用忍受那不停重启这种非人的折磨，这也使笔者深刻体会到，代码在哪个空间运行，不能由代码的功能属性来决定，而是应该由编写代码的团队来决定，由用户编写的代码应该运行在用户空间。把所有功能属性是设备driver的代码都放在内核空间运行，是一个面向过程的方法，而不是面向对象的思想，这点上，不得不说，是linux的一个遗憾。——软件工程中，面向对象的思想无处不在，而不仅仅在于如何书写代码。当然，linux最初设计在X86上运行，X86的IO指令是特权指令，只能在操作系统层操作，由于X86的先天特性，linux的驱动程序运行在操作系统空间能提高执行效率。现在linux也开始支持在用户空间的驱动程序，但有许多限制。
    在由多个子团队协同开发的项目中，项目经理以及系统工程师必须考虑的问题是，哪些模块放在一起编译，哪些模块共享命名空间，如果在支持多进程的环境下开发，则还要考虑哪些模块在相同的地址空间运行。这些问题集中到一起，就是如何划分“软件友好组”的问题。在《都江堰操作系统与嵌入式系统设计》一书的第3章，用了相当长的篇幅用于讲述友好组。
    友好组的定义很简单，就是可信赖的程序组成一个友好组，什么是可信赖的程序？同一个团队开发的程序是可信赖的。“友好”有两层意思，一是这些代码是为一个共同的目标，密切协作地完成任务；二是这些代码不会主动地、恶意地互相干扰和破坏，也不会故意执行非法操作。有两个特例是，如果同一个团队开发的两个模块将来可能会分成两个团队开发，应该将他们分成两个友好组；第二个特例是，两个模块的可靠性等级相差比较大，也应该分属两个友好组，这样，两个模块就可以使用不同强度的测试手段。
    以设计软件的人为核心，是都江堰操作系统的核心思想之一。现代软件开发中，非常强调工程化开发的思想，在工程化开发中，任何软件策略都不能不考虑人的因素。划分友好程序和可疑程序是 djyos 操作系统设计中的一个根本性的策略，划分的依据是开发团队，而不是以技术特征，是都江堰操作系统当然的选择。把协同工作的团队开发的所有代码称作友好程序，划入一个友好组，而把所有不协同工作的团队以及个人开发的程序当成可疑程序，主要考虑的是人的因素。根据这个原则，操作系统自身的所有代码是由一个核心团队开发的，当然地成为一个友好代码组，操作系统开发团队无需与开发应用程序的团队和个人协作，它把所有应用程序都当作可疑程序；同样，一个应用程序是由一个人或者一个密切协作的团队开发的，该程序的所有代码形成一个友好组，而把所有其他应用程序以及操作系统都视为可疑程序。这与传统的观念不同，传统的观念认为，操作系统是可信程序，而用户程序是非可信程序。
    djyos建立篱笆墙隔离友好组，使之不能互相影响和互相破坏，以及提供不同友好组之内完整的命名空间。根据硬件支持情况，友好组之间的保护分为两个级别：
1. 在多进程环境下实现物理隔离，使不同友好组拥有独立的寻址空间，他们之间的代码、数据在物理上互不可见，也就无法互相破坏。实现物理隔离的手段，就是下一节讲述的虚拟机。
2. 在平板内存模式下实现逻辑隔离，在编写软件时，同一个友好组的代码独立编译，拥有独立的命名空间，友好组之间的函数、变量互不可见，使其不能显式地互相破坏，但在物理上，他们共享寻址空间，用绝对地址（比如通过指针）是可以访问其他友好组的数据和代码的。