ARM kernel consolidation

翻译：李潇

你最近可能听说了内核中ARM架构存在的一些尴尬。鉴于ARM Linux的合并是Linaro特别要着手处理的问题之一，很自然你会想问“Linaro将怎么面对这个问题？” 所以当该话题成为了最近在匈牙利布达佩斯举行的Linaro开发者峰会的主旋律时，千万不要感到惊奇。

代码重复以及游离于主干开发流程之外的补丁，使得内核中的 ARM 部分尤其难以使用和开发。因此，Linaro正在合并代码并将代码推向主干。这将会让内核能更好的处理ARM板和SoCs。然而，ARM Linux内核合并并不是Linaro独自面对的问题，在整个ARM Linux内核社区，ARM Soc，ARM板和系统供应商也同样存在这些问题。因此，尽管我希望Linaro能起到关键作用，但最终的解决方案需要整个ARM社区的努力。另外很重要的一点是，这种努力只是一种尝试性的建议，而不是必须遵守的命令。

如果我们想要取得任何进步，我们必须从某些地方开始做起。一种极好的出发点是根据功能来组织ARM Linux内核代码而不是根据Soc/board实现。将有相同目标的代码聚集在一起将比较容易观察到相同的模式，甚至是相同的代码。比如，如今许多ARM SoCs用相似的“IP blocks”（比如I2C控制器），但是在相应的arch/arm/mach目录下每个SoC会提供一个完全不同的I2C驱动。我们期望在不同ARM板和SoCs上，相同硬件的“IP blocks”驱动能够合并为一个单独的驱动，并且该驱动能够使用相应IP block工作在任何系统上。在某些情况下，将一个给定的IP block与SoC或者ARM板连接起来有不同的方法，这样会带来些复杂度，但这样的复杂度总是可以被搞定的。

这样又出来了一个问题，相似的代码应该移到哪儿去。大家都同意的回答是，不应当移到arch/arm目录下。驱动理所当然要放到顶层drivers目录树的相应子目录下面。另外，ARM SoCs有内置多种不同的设备，从触摸屏到GPS接收器，再到加速感应器，而且新型设备还会不断出现。所以某些时候，将代码移动到某个驱动分类也不完全合适，而最好是在drivers树目录中创建一个新的分类。

但对非驱动代码该怎么办呢？它应该放在哪？看一看以下例子应该会有启发：（1）Jeremy Kerr，Russell King，Thomas Gleixner，还有很多其他人一直在开发的struct clk代码。（2）Grant Likely领导的device-tree代码。（3）Thomas Gleixner一直在开发的通用中断的芯片实现。

struct clk代码是由许多SoCs和ARM板里elaborate clock trees受到启发的。这些树在其他地方会用到，在性能和能源效率方面权衡，根据SoC或者ARM板上单个设备的需要作出设置。struct clk代码在提供插件去适应指定SoC或ARM板的同时，还允许这些树以通用的格式表示。通用中断芯片实现也有相似规则，但它跟时钟树无关，而是跟中断分布有关。

设备树的目的是用来允许通过数据而不是代码来表示ARM板的硬件配置，这能够减轻创建一个在不同ARM板上启动的单一Linux内核二进制的任务压力。设备树基础架构补丁已经在近期被Russell King接受，这说明从特定ARM板代码到设备树描述的转变将开始。

struct clk代码已经被同时用在了ARM和SH CPU架构中，所以它不是只对ARM适用的，而是更核心的Linux内核代码。同样的，设备树代码也不是只对ARM适用的，它同样被PowerPC, Microblaze和SPARC架构用到，甚至被x86架构用到。因此设备树也是Linux的核心内核代码。虚拟中断使用的更广泛，在所有CPU架构中都很普遍。这给我的启示是ARM内核代码合并不一定要限制在ARM上。事实上，一段特定代码支持的架构越多，愿意对它贡献代码和测试的开发者就会越多，这段代码就会越健壮，越具有可维护性。

当然，也需要有一些只针对ARM的代码，但是这些代码最终会限制为ARM核心架构代码和ARM SoC核心架构代码。而且，ARM SoC核心代码最终会演变为由针对核心Linux内核框架的小插件组成，这将会极大减轻新ARM板和SoCs的开发和维护。

很容易将这些做法写出来，但真正去实现它却是另外一回事。毕竟，尽管有一大批极有天赋和激情的ARM开发和维护人员，但是其中很多是ARM新手，对Linux内核也不熟，自然也不知道新代码该放在哪里。这些人可能很容易继续将他们的大部分代码放在SoC和ARM板子目录下，这将使得现存的ARM Linux内核难题继续存在。

解决方案的一部分是增加文档，特别是指导ARM驱动和ARM板端口开发的文档。Deepak Saxena，这位Linaro内核工作组的新领导者，即将开始这项工作。虽然只有当真正读到它时，文档才会发挥作用。但幸运的是，正如在计算机科学里任何问题似乎都可以通过增加额外的间接层来解决一样，任何维护上的问题似乎也都可以通过增加额外的git树和维护人员来解决。这些维护者将会帮助生成通用代码，在代码可用后自然也就成为文档的开发人员。

可以使用Nicolas Pitre现成的Linaro内核git树。然而，Nicola的git树是integration tree，就是说将最新的ARM相关代码合并到一个静态的主线版本。相反，maintainership tree面向的是计划合并进入上游的补丁，这些补丁是以下一个主流发布候选版本为根据的。如果我们用单一的git树来处理整合和维护，那我们要么不必要的将不相关的核心内核bug暴露给用户，要么我们不能足够紧密得跟踪主线内核用以维护，这将使得在每个合并窗口期开始的那一小段时间内，强制进行一个完整的rebase和测试期。

当然，理论上我们可以在同一个git树上有维护和整合分支，但是将这两个很不同的功能分开到不同的git树可能是初期最好的选择。

这个新的git树(公布于五月18)将在每一个参与的ARM子架构至少有一个分支，并且这些分支将不会受到rebase合并，这让在该git树上的开发变得容易。遵循惯例，参与ARM子架构的维护者将宣布该维护工作组发送该git树的 pull request。同样，遵循惯例，所有分支的合并请求将会发送到Stephen Rothwell的 -next 分支。这些分支也有可能通过Russell King的ARM树，独立推送给Linus Torvalds。

每个分支独立推送给Linus，这看起来很令人奇怪，但Linus的确希望看到由此产生的冲突。这样的冲突可能会帮助Linus找到需要他注意的地方。

无疑，这个新的git树将不会限制在Linaro内部，但也不仅仅给Linaro之外的同仁使用。我会非常高兴地看到一些Linaro之外的维护者表示有兴趣参与进来。

布达佩斯的会议推举出了这个git树的维护组成员，即Arnd Bergmann, Nicolas Pitre和Marc Zyngier,另外还有Thomas Gleixner提供帮助。Russell King当然也会拥有对该树的写权限。这个树将及时启动以应对2.6.41合并窗口期。该计划打算从小处开始不断迭代向前进化而不是一开始就设计一个完美模型。

正如文章开始提到的，这种努力是一种实验，而不是必须遵守的命令。尽管这个建议性的实验不能期望解决每个和任何ARM Linux问题，但他们将提供一个好的开始。每一点帮助，每一次清理释放一些时间来启动下一次清理。有理由希望这份努力会帮助减少无数的毫无意义的并让Linus Torvalds在上个月动怒的平台代码