贡献内核补丁（Kernel Mainlining）

原文：eLinux.org

翻译：@DecJude

校订：@lzufalcon

贡献内核补丁（Kernel Mainlining）

本文为嵌入式开发者介绍了如何往 Linux 内核主线贡献补丁。

通用资源

Documentation/HOWTO
- 说明了如何为 Linux 内核编写并贡献代码
Documentation/development-process
- 讲述了内核开发流程

训练，指导和挑战

内核新手网站是一个专注于帮助开发者学习如何往 Linux 内核做贡献的网站
- 该网站有一个”待做” 列表，上面是一些小的开发任务，地址在http://kernelnewbies.org/KernelJanitors/Todo
- 他们有个非常好的上游合并指南板块，那里有很多技术以及社群方面的技巧。
The Outreach Program For Women（女性推广项目）有一个非常好的指导步骤，是关于如何贡献你的第一个补丁到内核
- OPFW 第一个内核补丁教程
Eudyptula 挑战
- 这是一个通过邮件来管理的一系列任务，总共 20 个，用以帮助开发者学习如何开发内核并提交补丁。
- LWN.net 的文章：http://lwn.net/Articles/599231/
Linux 内核骇客新手指南

具体项目

CE 工作组设备 Mailining 项目
高通 SOC Mainlining 的项目
全志 Mainlining 的努力
- 这是一个相当好的网站，上面更新了已经合入各内核分支的补丁的状态，以及哪些些任务仍在进行中。

最佳行动说明

来自 Andrew Morton

工业界应当有一个嵌入式内核维护者
向内核社区上报问题和需求
参与社区论坛
企业应该贡献出几位工程师，独立于产品开发团队
基于最新的内核主线开发产品，产品开发结束时冻结它（译者注：不再和主线保持同步）。
- 从我所了解的看：目前 Android 相关模块和板级支持不在此列（译者注：主流 Android 设备都会不定时获得系统更新，包括了 Linux 内核)。
向社区（Andrew）寻求帮助

来自 Deepak Saxena

不要傲慢 - 不要试图把你在特定领域开发的经验照搬到开源领域
- 保持谦逊并听取其他人的想法
早点发布，频繁发布
- 不这样做的话，以后会浪费很多时间在实现的推翻和重写上面
个人练习
- 看看那些 Linux 内核已经实现了的部分，看它是否可以扩展来支持你的案子。
- 把实现加入到现有的抽象层，而不是用你自己的新潮的方案 (愿意去舍弃你自己的部分代码，只要最终你的相关模块可以得到社区支持)
不要添加 OS 层面的抽象实现（或者是来自其他操作系统的 HAL 层）
- 驱动程序必须是位于 Linux 内核层面 - 位于其他层和复杂的驱动程序没有办法被 Linux 内核开发者所维护
添加抽象实现 - 不要仅仅只解决你眼前的问题
- 实现支持多个相关硬件的系统方案
- 有意愿去推广普及
个人练习
- 使用 Mainlining 资源
- 提出有见解的问题
和社区协同工作，把他们看作是你自己的团队
- 把来自外部的开发者当作你的团队成员
- 尊重他们

来自 Jonathan Corbet

原因 <查看演讲稿>
专有软件和开源软件的差异
- 专有软件 = 产品驱动，自上而下的需求，短期，内部品控，层层决策，私有代码库，完全控制
- 开源软件 = 流程驱动，自下而上的需求，长期，外部品控，一致决策，公共代码库，轻度控制
理解补丁的生命周期
- 尽早发出来，通过社区解决问题
- 进入 staging 目录
- 被内核主线接纳
尽早发布，频繁发布
提交补丁
- 发送变更，即使不被接受也可以影响相关方向
- 不要有一对多的补丁，把每个补丁做到简单和独立
- 做出一分为二的补丁系列
- 遵循提交规则
  - 使用 diff -u，不带媒体信息，格式正确，添加署名行（Signed-off-by），避免自动换行
    watch word-wrapping
- 发送到正确的地方: MAINTAINERS（维护人员），可通过 get-maintainer.pl 工具自动获得
- 听取审核人的意见，要有礼貌，不要忽略他们的反馈
看开点
- 你的代码或许要重写或者被替换
写代码
- 遵循代码风格规范
  - 不要太多 (HAL 层，没有用到的参数，只有一行代码的函数)
    - 不要有支持多个 OS 的代码
  - 不要太少 - 如果相关实现已经有了，应当推广之
- 不要破坏 API
  - 只有在理由充分时才可以破坏内核的 API，但是你也必须把整个内核的相关部分都修复
  - 永远不要破坏用户空间的 API
- 不要引发衰退

来自 Arnd Bergmann

朋友，支持者和不速之客
不要（通过下述方式之一）骚扰你的内核维护者
- 公开你所有的代码，包括设备驱动
- 他们会很喜欢开源的 3D 嵌入式图形驱动
成为社区的一份子
付出和回报
- 分步解决
  - 使用公开的源代码
  - 修改源代码 - 给每个功能做一个 git 分支
  - 每个分支都应该有机会向社区提交
- 跨越浪潮
  - 尽可能的多去重构（译者注：应该是指 git rebase 来重构内核补丁，确保准备提交往内核的补丁足够逻辑清晰、代码干净）
- 把产品的代码树和开发的代码树分开
  - 把开发一直放在单独的分支进行
- 审核
  - 提供学习经验
  - 新来的人也可以评审，并且在这个过程中学习
- 尊重
  - 审核人 - 要认可开发者的努力工作，即使你不得不打回他们的提交
  - 提交人 - 应当尊重审核人的经验和知识，按他们的建议来做，即使你可能并不认同
- 拒绝
  - 维护者 - 拒绝差的代码比接受好的代码更为重要
- 责任
  - 不要仅仅只复制这些基础的部分，还要扩展它，推广它

来自 David Arlie

http://airlied.livejournal.com/80112.html

你有很长的一段路要走，但首先你要从家里离开

或是为什么公开代码才是 STEP ZERO.

如果你已经在内部开发好了准备往内核贡献的代码，你也许有很多原因不能一开始就默认选择开源，你也许不是在像 Red Hat 这样的默认支持开源政策的公司工作，或者是你可能害怕恐怖的内核社区，想自己成为一块闪亮的宝石。

如果你的公司正在遭受代码合法性评审等等之类的痛苦，可能你已经花费/浪费了好几个月的工程时间在内部评审和相关事项上，所以你还有什么理由不去考虑这些问题呢？你都已经浪费了这么多的时间在这些事上了，这绝对是个问题

所以如果你都有了优雅的代码库，那么内核维护者们有什么理由不喜欢去合入它们呢？！

然后，你就公开了你的代码。

看吧，你才离开你的屋子。而合入你的代码还有数英里远的距离，你才刚刚踏上路途，是从现在开始算起，不是在你开始写代码的时候，不是在你开始做代码合法性评审的时候，也不是当你私底下第四次重写代码的时候。你只是从现在开始。

也许你不得不公开重写的你代码多达 6 次，也许你永远没有机会让它合入进去，也许你的竞争对手也在进行这方面的工作，内核维护者更希望你去跟他人合作，”操纵民意”的做法只会让他们大发雷霆，这就是内核开发的过程。

STEP ZERO: 公开你的代码。离开屋子。

（最近我看到这样的问题越来越多，所以我决定把它写出来，这真的不是针对特定的任何人，因为我想大部分的厂商都会犯这样的问题）。

\< 文章是关于为何你应该立即公开你的代码>

这引发了这些问题:
- 为何要尽早开源？因为如果不这样的话，后续的工作量可能会加倍
- 立即开源代码的障碍是什么:
  - 依赖关系!!! （大部分是版本之间的差异）

克服 Mainlining 遇到的障碍

Tim Bird 为 2014 年欧洲嵌入式 Linux 会议准备了一篇关于克服 Mainlining 障碍的演讲。那篇文章里头有演讲信息和演讲稿的下载链接。

类别:

内核

贡献内核补丁