LWN: upstreaming 的困难！
关注了就能看到更多这么棒的文章哦～
The trouble with upstreaming
By Jonathan Corbet
September 27, 2021
Maintainers summit
DeepL assisted translation
https://lwn.net/Articles/870553/
内核开发社区一直在大声鼓励开发者把他们的代码放到 upstream 内核中。但是，将代码并入 mainline 的实际体验 往往比较困难，以至于一些开发者（和他们的雇主）干脆就放弃了这个打算。2021 年的内核维护者峰会花了一些时间来讨论社区是怎么做到让开发者做事变得更困难的，但同时却也没有想出多少办法能让事情变得更好。
Upstreaming agony(upstreaming 的痛苦)
Ted Ts'o 在会议开始时提到了本周早些时候举行的内核峰会（Kernel Summit）的一个讨论中，有几位 Chrome OS 开发者回顾了他们为合入 mainline 所做的努力。他特别提到了演讲 ppt 中的第 10 页，标题是 "Upstreaming agony"。那一页中提到有些维护者的反应比其他维护者快得多，而有些维护者则提出要求需要许多不相干的改动，还有更常见的："哦，我们当然可以把你的这两行改动合入进来……*只要你能先把这个 subsystem 完成重写"。Ts'o 说，这种不一致性可能会让新的开发者感到不快，这也可能是许多开发者选择不参与内核社区的原因。他问，怎样才能改善这种情况？
Linus Torvalds 回答说，在维护者的许多次聚会上都有类似的讨论。这个问题的一部分原因仅仅是因为所有的人不可能都是一样的，但是子系统之间也确实是有差异的。他说，内存管理子系统会影响一切东西，因此会比一些普通的驱动程序更难接受改动。我们确实有痛点，并且一些维护者确实把这个门槛提得太高了，但是他也确实没有看到解决这个问题的有效办法。他建议，对有问题的维护者进行 "naming and shaming （点出名字来给予压力）" 可能会有所帮助。
Dave Airlie 提到了一些厂商所遇到的问题。比如他们新推出一个 SoC，就可能涉及到需要将几十个驱动程序推送到 upstream 上，其中每一个都需要发送到不同的地方去，牵涉到不同的验收标准，才能进入 mainline。这使得做事困难变多了。Arnd Bergmann 回应说，对于基于 Arm 的 SoC 来说，有一个可以解决这个问题的方法，那就是他的 arm-soc 代码 tree。驱动程序都可以通过这个路径进入 mainline。
我忍不住指出，在之前关于这个话题的讨论中，大家决定创建一个 maintainer 手册，其中包括子系统的简介，并且每个子系统的怪癖都可以被记录在文档里。现在这个 maintainer 手册已经存在了，但其中的子系统简介部分几乎是空白的。因此，我们也就几乎没有任何文档可以帮助 patch 作者来针对性地处理某个特定子系统。Torvalds 建议反其道而行之，由开发者来记录他们与特定子系统合作中碰到的问题。他说，维护者不会考虑这些事情，但补丁提交者一定会考虑。
我表示，我可不想去接下这个任务来合入那些添加对其他维护者批评意见的 patch。
Chris Mason 提醒大家注意上一次会议结束时的讨论，其中涉及到了那些在公司内部工作比在 upstream 社区工作感到更快乐的开发者。即使是被视为核心开发者（core developer）的人也会有这种感觉。Mason 说，将代码上传到 upstream 的过程充满了不确定性，它会使 patch 变得更好，但这里需要付出的代价是使得开发者的生活更加艰难了。如果能找到什么方法来为这个过程增加一些确定性那就好了。在周一关于 folio 的讨论中，开发者 Matthew Wilcox 说，他不知道应该运行哪些测试来展示他的工作对性能有多少影响。Mason 说，当这样一个长期的核心开发人员都不知道的时候，我们肯定有些地方做的不够好。
Torvalds 回答说，当涉及到内存管理时，没有 benchmark，只有开发者所运行的 "成千上万的各种各样的任务"。他提到了 Phoronix 的基准测试，说他们发现的问题数量简直完全不合理。基准并不是万能的。最好的方案是能有一个人在持续跟进，并在一直跟踪性能数据。他说，他对 syzbot 测试感到不太满意，因为这些测试都是在大量英特尔机器上运行的，哪怕仅仅只是移动一个 cacheline，都会显示出性能退步了。对于性能测试来说，这里的帮助并不是很大。[注意，Torvalds 说的是 "syzbot"，但他似乎是指英特尔的 0day 测试。]
Al Viro 补充说，如果能有人报告出 regression 的话确实很好，但更有用的是结果值的标准差（standard deviation）。他见过许多报告声称有性能改进，但一旦仔细看了数据，就会发现这里的所谓改进 "基本上都是噪音数据"。Torvalds 指出，Syzbot 测试确实至少还是提供了测试结果的标准差的。
Thomas Gleixner 说，社区可以把正式标准写到文档里，但要想记录清楚对于代码设计的那些期望可就困难多了。事实上，不同领域有不同的标准，这就更增加了困难度。而且，一般来说人们都不会听这些指导意见，而只是 "把东西塞进代码角落里"。Mason 问，会不会也是给予开发者的一些指导的语气让人更加无法接受？有时开发者们会觉得在 review 过程中一直在被打压。Gleixner 回答说，他主要是在提问，并且花时间向没有经验的开发者解释这些问题。不过，当他面对那些不听话的有十年经验的老手时，他就放弃了。Mark Brown 补充说，社区以前多次讨论过语气问题，而这往往会归结为文化上的差异。
在这个没有结论的会议结束之时，Ts'o 又提出了一个观点：许多开发者想在社区之外提供对 kernel 的贡献，因为这样感觉更容易一些。如何解决这个问题，并不是很清楚。开发者可以工作的许多领域都影响着大量的用户。很容易做出一个对某个场景来说很好的 patch，但它却同时破坏了其他的场景。在大公司里，开发人员因解决公司的问题而得到奖励，而为社区做出贡献并为每个人改进内核则很难得到什么奖励。他说，我们需要做得很好，找到方法来指出那些使内核普遍改善的开发者，并且给出奖励。
他继续说，一个常见的情况是，某个新的硬件功能的首位开发者会被要求做一个全新的框架，要求在一般情况下都要能用的起来。他说，user interrupt patch set 目前正在经历这种情况。这是英特尔的新功能，但是开发人员正在询问它在其他架构上将会如何使用。这是一个很难回答的问题，因为其他 CPU 制造商还没有说他们是否会提供该功能，或者以什么形式提供。他说："我们需要对第一个进入新领域的开发者更加宽容。"
接下来，会议室陷入了沉默，讨论转入了下一个话题。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～