Linux内核工程导论——如何贡献内核代码

内核开发周期

你写好了一部分内核代码要提交给内核的恰当时机是当内核的合并窗口打开的时候，一般持续2个周，之后发布rc1版本，rc1之后一般只对合并窗口添加的代码进行测试和修改，而不添加新的功能（新的硬件驱动除外）。这个修改会根据程序一直持续到到rc7甚至rc9，最后发布稳定版本。然后再打开合并窗口。

在rc测试并稳定的过程中，造成bug较多的合并可能会被回朔，而从内核中剔除，所以提交给内核之前开发者应该进行充分的测试。

提交patch

         提交的patch必须经过社区内核维护者的充分测试，他们一般都不是全职的，所以良好的文档是必要的。测试稳定后会有Linus本人合并进内核，但是如果出现了问题，patch作者有责任修改，否则不予合并。稳定发布之后，patch的作者有责任继续维护，否则这个patch很可能被后续取消（例如devfs）。

         内核分为很多个子系统，每个子系统都有对应的维护者，提交的patch并不是提交给linus本人，而是提交给对应子系统的维护者。每个维护者都只接受只修改本部分代码的patch，经过其长期的测试和稳定后，当合并窗口打开，子系统维护者会要求linus合并其维护的patch进mainline，linus对维护者无条件信任，不经过后续测试。各个维护者之间可能会互相合并代码，比如网络部分和对应网络设备驱动是两个不同的维护者，但是其代码是相关的，这就需要其二位私下合并测试。

内核代码树维护

         linus本人当然维护的是mainline的内核树，这也是大部分用户下载内核代码的地方。然而当要提交一个patch的时候，却不是提交到mainline，各个子系统的维护者如何能确保自己选取的patch不会与其他子系统选取的要合并的patch冲突？这就需要对其他人选择的patch有个前瞻性的了解，维护者可以逐个去pull其他维护者的代码，但是这是风险很大，因为其尚未稳定。

http://www.kernel.org/pub/linux/kernel/next/

         维护的是下个版本要合并的全部的patch，在合并之前，所有的patch都要进入该代码树，其维护者是Stephen Rothwell。

         在mainline中也有一个维护不成熟驱动的专门的地方，位于driver/staging，如果你想找点活干，在这里有很多要多的事情的列表。你自己写的驱动未经过充分测试前也会放在这里面，维护人是Greg Kroah-Hartman。这里面的驱动如果经常有更新和修复，等到趋于完善后会进入合适的内核正式代码，如果长时间没有更新，则可能会被删除掉。