Forking the ARM kernel?

翻译：李潇/林业

在过去的几个月里，许多人都提出了建议将ARM与内核分离出来，将之作为一个独立的项目来维护。或许分离ARM的理由对一些人来说看起来是很有吸引力的，在这些人看来无论对于ARM社区还是内核，作为一个整体没有太大的意义。

1. 更容易把握市场时机

2. 它符合消费性电子产品一次性的性质

3. 它更符合SoC世界的多样性

4. 它避免了维护者的瓶颈和代码审查之类的一些无用的额外工作

市场时机

持这种观点的人认为，hack出一个新的驱动程序所需要的时间要小于让 Linus 等接受它。我知道我学识很老，不再懂这个快速变化着的世界和半导体工业的新挑战，但是，我仍然有许多的工程学的知识和常识以至于我知道在这个工业里根本没有什么真正的、和过去完全断开的新东西。大多数 SoC 的IP模块并不是新的。所以当IP模块第二次被应用的时候市场时机又有何变化？如果一个驱动程序是 upstream 的，它可以很容易的被复用，但是常常的情况是，一个新的驱动程序从头开始编写，完成的时候仍然有一堆漏洞需要修正。当重写那些他们所出售的SoC IP模块新驱动程序的时候，供应商们真的得到了更好的时机么？

此外，真正一个完整的新一代的芯片市场化的时机不是几周就能衡量出来的。通常情况下，对于一个新的芯片从市场发布到稳定应用到设备上需要大约一年时间。这是对于得到一个新的驱动程序有了足够的时间。而且，市场发布的时间显然不应该是在工程部喝点啤酒，几个天才工程师在酒吧的草纸上勾勒出个设计的第二天，所以大多数的项目应该有更多的时间去推向 upstream。

嵌入式商品是一次性的

对于嵌入式的项目，特别是在消费品市场，硬件是一次性的是毫无争议的，但是另外一个事实是，SoC family 在很多方面是普遍的，只在一些小细节方面有所不同。此外，特定硬件的不同变种（比如智能手机）共用了绝大多数的基础架构而只在一些特定功能上存在差异。新一代 SoC 往往会有很多的上一代的模块被嵌入其中，因为没有令人信服的理由去取代那些已经被证明构建好且可以实现充足功能的模块。复用那些已知的的可以工作的部分不是一个新的概念，而且毋庸置疑的是实现市场化目标的一个基本的部分。

最近我们身上发生了这么一件事：一个几乎所有的外部组件都已经在内核主线中得到完美支持的 SoC 进行了升级。CPU 内核被替换，但外围组件保持一致——除了为符合新 CPU 核心所作的一些 VHDL 的细微改动。现在我的工程师性格也许应该期待Linux对于B代片上系统的支持只存在调整现有的驱动程序这样的小问题而已。现实是供应商们组建了一个小组去开展对“新”的片上系统和所有从头重写的驱动程序的支持。与此同时我们抓到一些驱动程序去审阅，而另一些进入了主线，所以我们为同一片半导体硅得到了两个完全不相同的驱动程序。

有一段时间，我非常难以接受这样一种观点：宁可从头开始重写成打的驱动程序也不愿坐下来鉴定那些已经存在的、被证明可以工作的驱动程序，根据新的 SoC 的设计去修改它们。嵌入式工业经常复用硬件，为什么就不能同样复用软件呢？

SoC 的多样性

无疑，每一个 SoC 供应商都会叫喊他的芯片在所有方面都是独一无二与众不同的，共享很多的代码基本是不可能的。从市场方面很容易理解这些，但是如果你深入查看 SoC 的数据表，独特的外围模块数量并没有多令人兴奋的增加，鉴于该系统芯片供应商相同的市场目标和相同的客户群，或多或少的预期。一份调查揭示了不同的供应商经常使用相同的或十分相似的IP模块去实现一个给定的功能。只有很少数量的功能性方法去实现一个给定的硬件需求，而且只有很少的相关IP模块供应商把自己“独一无二”的构建模块提供给其他的 SoC 供应商。差异性常常只是局限于供应商们在登记注册的安排上以及不同的供应商选择不同的功能子集这件事实上。

我们最近看到了一些被证明是正确的内核合并工作，当清理中断子系统时我注意到只有两种广泛运用的中断控制器。不用投入太多努力就可能将30个声称有“与众不同”的芯片实现代码全部替换掉。一个相似的成就是，在替换掉许多重复的通用输入输出（GPIO）芯片的支持代码过程中，这些都是很容易得到的成果并且有更潜在的合并方法。

避免无用工作

与那经常只有很少的时间去复审的维护人员们打交道似乎是一个瓶颈。那些导致了提出复审评论的额外的工作也看起来像是浪费时间。维护人员的数量和复审可用的时间固然是一个需要注意的限制性因素。复审的能力对于那些维护着一个特定内核的子系统的人不是限制，并且我们希望看到更多的人参与到复审的进程中来。花一点时间去复审别人的代码是一个收益巨大的工作，它就像对所有接近者打开了一个人的思想以使他们更好的理解全面的状况。

从另一方面来讲，让别人复审自己的代码也是很有益处的，一般来说可以让你的代码更好和更具可维护性。并且为我们避免在下一个项目中犯错提供了帮助。在最近的一次已经进行过很多轮的复审中，一个1200行的驱动程序被缩小到了250行，并且少量的漏洞和主线错误得到了修正。

我曾经有机会在一个冗长的复审进程之后和开发者们谈话，他们中的大多数人承认学习和理解更多的Linux开发方式的机会的痛苦要大于复审进程和一些必要的回顾工作。当检查最近的补丁时我经常注意到，这些开发者已经提高并且避免了一些在第一次尝试时所犯的错误。所以复审对于开发者和他们的公司来说都是有益的，复审帮助他们用更高效的方法写出更好的代码。我称呼那些仍然叫嚣着复审和其所带来的工作是主要障碍的人为表里不一的，他们在努力把他们所在公司的责任转嫁归咎到的内核社群。

一个问题是不培训他们如何同Linux社区一起工作就指定专有的实时系统（RTOS）开发者们去写Linux内核代码。不懂如何同Linux社区一起工作不是什么羞耻，毕竟，包括我自己在内每一个内核开发者都是从一个不知道的点开始着手的。但是它花费了我一段时间去学会如何同社区一起工作，而且它也将花费那些专有 RTOS 的开发者们一些时间去学会和社区一起工作，这些所付出的时间和努力都是值得的。

Fork ARM内核后，需要解决哪些问题？

假如有一个专门的ARM GIT仓库，扮演一个所有Vendor trees的堆积站。它将不时地把主线内核的增强功能吸收进来，这样的话，嵌入开发人员就能获得新的文件系统特性和网络特性等。推断出近期流向Linux的SoC支持补丁，移除掉这上面的所有正确性检查将导致那个ARM树的增长率立即超过所有主流内核的增长率。并且，如果主线内核的增强功能像需要我最近的一些工作有所改动一样，也需要ARM树的所有驱动都改动的话，那该怎么办啊？谁来完成这些改动？如果驱动都在主线内核里面，驱动是作为这些增强功能的一部分发生改动。如果有一个单独的ARM fork，一些ARM-fork的维护者将不得不完成这些改动。

而且，谁来维护这样一个树？我严重怀疑是否会突然出现足够的有经验并有资格去处理这样一大堆改动的维护人员。维护人员在与主线内核打交道时，他们有所抱怨，为了避免这些，他们也许只会扮演集成者的角色，仅仅是在中央区域对各个Vendor trees进行合并。

我们会从这样一个动作中收获什么？据我看来，我们将一无所获，它仅仅是让所有人都声称他们所有的代码是一个神秘的ARM Git tree的一部分。当然短期内，这样会完成最终的产品上市要求。

ARM-fork能支撑多久呢？

我严重怀疑ARM复制树能活得过若干个内核周期，原因很简单，核心代码的改动将导致不兼容SoC API产生完全不具有维护性的#ifdef混乱，这会让任何不得不维护这样一个“野兽”的人立刻抓狂。我十分确定没有一个ARM-fork的支持者曾经试过将五个vendor trees拉取到一个单独的内核树上，并处理DMA APIs，驱动子系统，基础结构的冲突改动。我知道嵌入式内核的维护者的确因为这些原因立即变得绝望，我怀疑任何一个合理的内核开发人员会足够发疯到花掉不止几个月的时间去处理这样一件恐怖的事情。

除了它那令人怀疑的用处外，这样一个ARM fork将会从对Linux内核所有方向的影响中完全地切断ARM世界。对大部分有经验的主线维护者和开发者而言，ARM将变成一个毫无兴趣的领域。我怀疑尤其是当操作系统层面的软件的复杂性正在稳固增加的情况下，ARM行业能否禁得起以这种方式将自己断开联系。

有更好的方法吗？

从没有一个方法能从根本上解决所有的问题，但是有一些小的方法可以有效地解决主要问题点。

导致出现现在这种状况的根源之一是它的历史本质。二十多年来，ARM行业与那些不可能改变核心代码和不可能与之进行有竞争的合作的闭源操作系统打交道。如今，迁移到Linux以后，ARM的大部分都还在这个著名的模型下工作，并且让那些在转到Linux之前也在以其他操作系统上工作过的工程师继续按照过去的方式让他们的系统工作。这对管理层也是一个完美的解决方案，因为现有的自上而下进行软件开发和管理的结构和思想依然适用。

只要由此产生的代码不用集成到主线内核并且每个厂商维护它自己特有的复制品，这种解决方案貌似是有效的。有时会从客户那里传来主线内核集成的合理请求，然而，当这种方案让采用新特性变得更容易的时候，对冻结的厂商内核的依赖就会越少，并且，从最近可以看出，该方案允许对多平台的合并。后者能让合理的发行以上网本、平板电脑和相似设备作为目标工作，这是很重要的。它甚至对长期传言的在不久将来将成形的ARM服务器同样适用。这样的合并不仅需要ARM厂商的合作，还需要主线内核许多方面的合作，同时也需要那些不一定是ARM领域的维护人员和开发人员的合作。

因此，我们需要让管理层明白到坚持这个有名的模型并不是解决逐渐增加的SoC硬件复杂性以及开源世界中开发高效和可持久性操作系统带来的挑战的最有效方法。同时，我们需要解释一下在工程的层面上将Linux与其他OS平台以同样的方式对待的话，将会让前进更加艰难，至少当代码审查出现在邮件列表的时候，将是很让人痛苦的。

另外一个我们需要努力做的地方就是大量的协作性合并，这些合并需要先让芯片提供商至少在OS工程层面上接受他们的SoCs并不是销售部想让他们相信的那样独一无二。正如我以上提到的那样，尤其是对低复杂性的硬件，仅有有限的几种方式去实现硬件上指定的功能。因此，我们需要鼓励开发人员首先去看一看现有代码是否可以重构以适应新的设备，而不是轻率的拷贝最接近的驱动（或者在最差情况下随机拷贝一个驱动），并设法以hack的手段去适应新的设备。

另外，内核维护人员也需要对这种情况更加警觉，并且帮助开发人员避免重新造轮子。如果不能达到驱动再利用的目的，我们可以将通用功能取出来放到核心代码里面，避免那样的重复。有很多唾手可得的东西在那儿，Linux整个内核社区需要变得更好并且花更多的心思去避免代码重复。

最近Linaro发起的ARM SoC合并提前开始了这样的行动。但是仅当我们意识到与现有公司文化的冲突并在非技术层面上解决掉这些冲突的情况下，代码合并才会成功。

保密

除了上面的这些问题，秘密堡垒将成为下一个主要的挑战。当然，芯片提供商可以对它下一代SoC设计保密，但是它在营销公告透露的信息至少能让我们准确地预测出部分设计。

最明显一个例子是以2011剩余时间作为目标的各芯片供应商提供的下一代ARM SoCs。其中很多都会支持USB 3.0。从 IP block vendor 提供的信息知道，相比较计划支持 USB 3.0 的 SoC 数目来说，支持 USB 3.0 的 IP block 极少。那意味着在里面有重复的驱动，我很确信这一点，工程师都知道没有那个团队会被允许跟竞争者的团队交流。即使他们被允许这么做，也不可能猜测出谁会用哪一个特定的IP block。所以当秘密堡垒出现时，我们会看到几个工程团队在几个月内为了让自己的“正确”实现能被合并到主线驱动而争斗。

为了代码实现而竞争不是一件坏事，但是不能交流信息、讨论设计变化不会对任何一方在“上市时间”的竞赛中有所帮助。我严重怀疑任何一个即将发布的驱动会有相关的竞争性优势，即使它有这种优势，当代码公开后这个优势也不会持续太久。相互协作以及为所有参入进来的组织保留先前的工程资源的机会被牺牲掉，而却用来以竞争为导向的行为样式上，这让人很伤心。这些样式还没被改革掉，因为他们不过只有二十多年的时间，还从来没有遭到开源操作系统竞争环境的审查。

前进之路

逐渐增加的硬件复杂性，产生了更多的操作系统层面上的软件，导致知名度高的OS层面的软件开发人员长久以来短缺，而这不是能用金钱或者通过安排大量的脸颊开发人员能够抵消掉的。ARM领域是如此多样化以至于所有提供商都没有机会得到足够数量的杰出内核开发人员，对他们的竞争者产生严重的破坏。在这个事实下，这个观点相当正确—那就是那些杰出的开发人员普遍更愿意工作在开源环境下而不是半封闭环境下。

大概是时候让管理者们反思他们的竞争模式并开始理解和利用协作模式的大量优势。有能力的开发人员当然不会放弃这个机会让自己加薪，但是若能得到更让人享受的工作环境，虽然薪水稍微低一些，对很多人来说却是一个强大动力去拒绝加薪的诱惑。对我来说，没有“上市时间”竞赛，没有股东利益手册，没有人力资源管理课程的想法是很吸引人的。

我希望为嵌入式提供商工作的管理者能够开始去理解开源是怎么运转的以及为什么与这个社区合作会有巨大好处。毕竟，平庸的、老旧的服务器提供商都能想出如何与Linux社区合作，因此对快速移动的嵌入式提供商也不是那么难的事。然而，我是一个现实主义者——有时被称为脾气暴躁的老人——在嵌入式行业做了超过二十五年的时间，一点不相信真会这样。对如此多的SoC提供商而言，做出与社区合作的决定是出于外界的压力和炒作。

外界压力不是开源狂热者所希望的那样由开源社区本身的影响力造成的。不是的，他只不过是客户要求芯片至少基本上被主线内核支持所造成的压力。炒作是无处不在的，似乎总可以称为一个有效的理由去避免基于长期考虑所做的常识性决策。

我身上的永久乐观主义仍然希望嵌入式世界很快会成为Linux社区的一等公民。而我身上的现实主义却又怀疑在我这个脾气暴躁的老人退休之前它是否会发生。