Warning
此文件的目的是为让英文读者更容易阅读和理解,而不是作为一个分支。为此,假若您对此文件有任何意见或更新,请先尝试更新原始中文文件。
Note
倘若您发觉本文档与原始文件有任何不同或则有翻译问题,请联系该文件的译者,或则恳求时奎亮的帮助:。
Original
Translator
时奎亮AlexShi
校译
吴想成WuXiangCheng
2.开发流程怎样进行
90年代初期的Linux内核开发是一件相当松散的事情,涉及的用户和开发人员相对较少。因为拥有数以百万计的用户群,且每年有大概2000名开发人员参与进来,内核因而必须发展出许多既定流程来保证开发的顺利进行。要参与到流程中来,须要对此流程的进行形式有一个扎实的理解。
2.1.总览
内核开发人员使用一个松散的基于时间的发布过程,每两到三个月发布一次新的主要内核版本。近来的发布历史记录如下:
5.0
2019年3月3日
5.1
2019年5月5日
5.2
2019年7月7日
5.3
2019年9月15日
5.4
2019年11月24日
5.5
2020年1月6日
每位5.x版本都是一个主要的内核版本,具有新特点、内部API修改等等。一个典型的5.x版本包含大概13000个变更集,变更了几十万行代码。为此,5.x是Linux内核开发的前沿;内核使用滚动开发模型,不断集成重大变化。
对于每位版本的补丁合并,遵守一个相对简单的规则。在每位开发周期的开头,“合并窗口”被打开。这时,被觉得足够稳定(但是被开发社区接受)的代码被合并到主线内核中。在这段时间内,新开发周期的大部份变更(以及所有主要变更)将以接近每晚1000次变更(“补丁”或“变更集”)的速率合并。
(顺便说一句,值得注意的是,合并窗口期间集成的修改并不是陡然形成的;它们是经提早搜集、测试和分级的。稍后将详尽描述该过程的工作方法。)
合并窗口持续大概两周。在这段时间结束时,LinusTorvalds将申明窗口已关掉linux内核邮件列表,并释放第一个“rc”内核。比如,对于目标为5.6的内核,在合并窗口结束时发生的释放将被称为5.6-rc1。-rc1版本是一个讯号,表示合并新特点的时间早已过去,稳定下一个内核的时间早已到来。
在接出来的6到10周内,只有修补问题的补丁才应当递交给主线。有时会容许更大的修改,但这些情况极少发生;企图在合并窗口外合并新功能的开发人员常常受不到友好的接待。通常来说,假如您错过了给定特点的合并窗口,最好的做法是等待下一个开发周期。(时常会对未支持硬件的驱动程序进行例外;假如它们不改变已有代码,则不会造成回归,应当可以随时被安全地加入)。
随着修补程序步入主线,补丁速率将随着时间的推移而变慢。Linus大概每周发布一次新的-rc内核;在内核被觉得足够稳定并最终发布前,通常会达到-rc6到-rc9之间。之后,整个过程又重新开始了。
比如,这儿是5.4的开发周期进行情况(2019年):
五月15
5.3稳定版发布
五月30
5.4-rc1合并窗口关掉
五月6
5.4-rc2
五月13
5.4-rc3
五月20
5.4-rc4
五月27
5.4-rc5
十一月3
5.4-rc6
十一月10
5.4-rc7
十一月17
5.4-rc8
十一月24
5.4稳定版发布
开发人员怎样决定何时结束开发周期并创建稳定版本?最重要的指标是先前版本的回归列表。不欢迎出现任何错误,并且这些破坏了原先能工作的系统的错误被觉得是非常严重的。为此,致使回归的补丁是不受欢迎的,很可能在稳定期内删掉。
开发人员的目标是在稳定发布之前修补所有已知的回归。在现实世界中,这些完美是很难实现的;在这些规模的项目中,变数太多了。须要说明的是,延后最终版本只会使问题显得更糟;等待下一个合并窗口的修改将变多,造成上次出现更多的回归错误。因而linux内核邮件列表,大多数5.x内核都有一些已知的回归错误,不过,希望没有一个是严重的。
一旦一个稳定的版本发布linux更改ip地址,它的持续维护工作就被移交给“稳定团队”,目前由GregKroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发布稳定版本的更新。要合入更新版本,补丁必须(1)修补一个重要的缺陷,且(2)早已合并到下一个开发版本主线中。内核一般会在其初始版本后的一个以上的开发周期内收到稳定版更新。诸如,5.2内核的历史如下(2019年):
七月7
5.2稳定版发布
七月13
5.2.1
七月21
5.2.2
七月26
5.2.3
七月28
5.2.4
七月31
5.2.5
...
...
五月11
5.2.21
5.2.21是5.2版本的最终稳定更新。
有些内核被指定为“长期”内核;它们将得到更长时间的支持。在本文中,当前的常年内核及其维护者是:
3.16
BenHutchings
(常年稳定内核)
4.4
GregKroah-Hartman&SashaLevin
(常年稳定内核)
4.9
GregKroah-Hartman&SashaLevin
4.14
GregKroah-Hartman&SashaLevin
4.19
GregKroah-Hartman&SashaLevin
5.4
GregKroah-Hartman&SashaLevin
常年支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。目前还没有为正式发布的任何特定版本提供常年支持的已知计划。
2.2.补丁的生命周期
补丁不会直接从开发人员的按键步入主线内核。相反,有一个稍为复杂(假如有些非即将)的过程,借以确保对每位补丁进行质量审查,并确保每位补丁实现了一个在主线中须要的修改。对于小的修补,这个过程可能会很快完成,,而对于较大或有争议的变更,可能会持续数年。许多开发人员的失望来自于对这个过程欠缺理解或则企图绕开它。
为了减轻这些挫败,本文将描述补丁怎么步入内核。下边的介绍以一种较为理想化的形式描述了这个过程。更详尽的过程将在前面的章节中介绍。
补丁一般要经历以下阶段:
内核开发人员(或她们的雇主)犯的最大错误之一是企图将流程简化为一个“合并到主线”步骤。这些方式总是会让所有相关人员倍感欣慰。
2.3.补丁怎么步入内核
只有一个人可以将补丁合并到主线内核储存库中:LinusTorvalds。并且,在步入2.6.38内核的9500多个补丁中,只有112个(大概1.3%)是由Linus自己直接选择的。内核项目早已发展到一个没有一个开发人员可以在没有支持的情况下检测和选择每位补丁的规模。内核开发人员处理这些下降的方法是使用围绕信任链建立的助理系统。
内核代码库在逻辑上被分解为一组子系统:网路、特定体系结构支持、内存管理、视频设备等。大多数子系统都有一个指定的维护人员,其总体负责该子系统中的代码。这种子系统维护者(松散地)是她们所管理的内核部份的“守门员”;她们(一般)会接受一个补丁以包含到主线内核中。
子系统维护人员每位人都管理着自己版本的内核源代码树,一般(并非总是)使用Git。Git等工具(以及Quilt或Mercurial等相关工具)准许维护人员跟踪补丁列表,包括作者信息和其他元数据。在任何给定的时间,维护人员都可以确定他或她的储存库中的什么补丁在主线中找不到。
当合并窗口打开时,顶尖维护人员将要求Linus从储存库中“拉出”他们为合并选择的补丁。假如Linus同意,补丁流将流向他的储存库,成为主线内核的一部份。Linus对拉取中接收到的特定补丁的关注程度各不相同。很显著,有时他看上去很关注。并且通常来说,Linus相信子系统维护人员不会向下游发送坏补丁。
子系统维护人员反过来也可以从其他维护人员那儿获取补丁。诸如,网路树是由首先在专用于网路设备驱动程序、无线网路等的树中积累的补丁建立的。此储存链可以任意长,但极少超过两个或三个链接。因为链中的每位维护者都信任这些管理较低级别树的维护者,所以这个过程称为“信任链”。
其实,在这样的系统中,获取内核补丁取决于找到正确的维护者。直接向Linus发送补丁一般不是正确的方式。
2.4.Next树
子系统树链引导补丁流到内核,但它也提出了一个有趣的问题:假若有人想查看为下一个合并窗口打算的所有补丁如何办?开发人员将感兴趣的是,还有哪些其他的修改有待解决,以了解是否存在须要担忧的冲突;诸如,修改核心内核函数原型的修复程序将与使用该函数旧方式的任何其他修复程序冲突。审查人员和测试人员希望在所有那些变更抵达主线内核之前,就能访问它们的集成方式的变更。您可以从所有相关的子系统树中提取修改,但这将是一项复杂且容易出错的工作。
解决方案以-next树的方式出现,在这儿子系统树被搜集以供测试和审查。这种树中由AndrewMorton维护的较老的一个,被称为“-mm”(用于显存管理,创建时因此)。-mm树集成了一长串子系统树中的补丁;它还包含一些致力帮助调试的补丁。
除此之外,-mm还包含大量由Andrew直接选择的补丁。这种补丁可能早已发布在电邮列表上,或则它们可能应用于内核中未指定子系统树的部份。同时,-mm作为最后手段的子系统树;假如没有其他显著的路径可以让补丁步入主线,这么它很可能最终选择-mm树。累积在-mm中的各类补丁最终将被转发到适当的子系统树,或则直接发送到Linus。在典型的开发周期中,大概5-10%的补丁通过-mm步入主线。
当前-mm补丁可在“mmotm”(-mmofthemoment)目录中找到:
~akpm/mmotm/
但是,使用MMOTM树可能会非常令人头痛;它甚至可能难以编译。
下一个周期补丁合并的主要树是linux-next,由StephenRothwell维护。按照设计linux-next是下一个合并窗口关掉后主线的快照。linux-next树在Linux-kernel和Linux-next电邮列表中发布,可从以下位置下载:
Linux-next已然成为内核开发过程中不可或缺的一部份;在一个给定的合并窗口中合并的所有补丁都应当在合并窗口打开之前的一段时间内找到步入Linux-next的方式。
2.5.Staging树
内核源代码树包含drivers/staging/目录,其中有许多驱动程序或文件系统的子目录正在被添加到内核树中。它们在一直须要更多的修正的时侯可以保留在driver/staging/目录中;一旦完成,就可以将它们移到内核中。这是一种跟踪不符合Linux内核编码或质量标准的驱动程序的方式,人们可能希望使用它们并跟踪开发。
GregKroahHartman目前负责维护staging树。仍须要修正的驱动程序将发送给他,每位驱动程序在drivers/staging/中都有自己的子目录。不仅驱动程序源文件之外,目录中还应当有一个TODO文件。TODO文件列举了驱动程序须要接受的暂停的工作,以及驱动程序的任何补丁都应当抄送的人员列表。当前的规则要求,staging的驱动程序必须起码正确编译。
Staging是一种让新的驱动程序步入主线的相对容易的方式,它们会辛运地造成其他开发人员的注意,并迅速改进。但是,步入staging并不是故事的结尾;staging中没有见到常规进展的代码最终将被删掉。经销商也倾向于相对不乐意使用staging驱动程序。为此,在成为一个合适的主线驱动的路上,staging仅是一个中转站。
2.6.工具
从里面的文本可以看出,内核开发过程在很大程度上依赖于在不同方向上集聚补丁的能力。假如没有适当强悍的工具,整个系统将难以在任何地方正常工作。关于怎么使用这种工具的教程远远超出了本文档的范围,但还是用一点篇幅介绍一些关键点。
到目前为止,内核社区使用的主要源代码管理系统是git。Git是在自由软件社区中开发的许多分布式版本控制系统之一。它特别适宜内核开发,由于它在处理小型储存库和大量补丁时性能十分好。它也以无法学习和使用而闻名,虽然随着时间的推移它显得更好了。对于内核开发人员来说,对Git的某种熟悉几乎是一种要求;虽然她们不将它用于自己的工作,她们也须要Git来跟上其他开发人员(以及主线)正在做的事情。
如今几乎所有的Linux发行版都打包了Git。Git主页坐落:
此页面包含了文档和教程的链接。
在不使用git的内核开发人员中,最流行的选择几乎肯定是Mercurial:
Mercurial与Git共享许多特点,但它提供了一个界面,许多人认为它更便于使用。
另一个值得了解的工具是Quilt:
Quilt是一个补丁管理系统,而不是源代码管理系统。它不会随着时间的推移跟踪历史;相反,它面向依据不断发展的代码库跟踪一组特定的修改。一些主要的子系统维护人员使用Quilt来管理准备向下游联通的补丁。对于个别树的管理(比如-mm),quilt是最好的工具。
2.7.电邮列表
大量的Linux内核开发工作是通过短信列表完成的。倘若不加入起码一个某个列表,就很难成为社区中的一个“全功能”成员。并且,Linux电邮列表对开发人员来说也是一个潜在的危险,她们可能会被一堆电子电邮吞没、违反Linux列表上使用的约定,或则二者兼而有之。
大多数内核电邮列表都在上运行;主列表坐落:
不过,也有一些列表托管在别处;其中一些列表坐落/mailman/listinfo。
其实,内核开发的核心电邮列表是linux-kernel。这个列表是一个令人生畏的地方:每晚的信息量可以达到500条,噪声很高,谈话技术性很强linux防火墙设置,且参与者并不总是表现出高度的礼貌。而且,没有其他地方可以让内核开发社区作为一个整体集聚在一起;不使用此列表的开发人员将错过重要信息。
以下一些提示可以帮助在linux-kernel生存:
最后一点——找到正确的电邮列表——是开发人员常出错的地方。在linux-kernel上提出与网路相关的问题的人几乎肯定会收到一个礼貌的建议,转入netdev列表上提出,由于这是大多数网路开发人员常常出现的列表。还有其他列表可用于scsi、video4linux、ide、filesystem等子系统。查找电邮列表的最佳位置是与内核源代码一起打包的MAINTAINERS文件。
2.8.开始内核开发
关于怎么开始内核开发过程的问题很常见——个人和公司皆然。同样常见的是失误,这促使关系的开始比本应的更困难。
公司一般希望聘请著名的开发人员来启动开发团队。实际上,这是一种有效的技术。但它也常常是高昂的,并且对降低有经验的内核开发人员的数目没有多大帮助。考虑到时间投入,可以让内部开发人员推进Linux内核的开发速率。借助这段时间可以让雇主拥有一批既了解内核又了解公司的开发人员,还可以帮助培训其他人。从中期来看,这一般是更有利可图的方式。
可以理解的是,单个开发人员常常对起步倍感沮丧。从一个小型项目开始可能会很吓人;人们常常想先用一些较小的东西来试试水。由此,一些开发人员开始创建修复拼写错误或轻微编码风格问题的补丁。不幸的是,这样的补丁会形成一定程度的噪声,这会分散整个开发社区的注意力,因此,它们越来越被人不看重。希望向社区介绍自己的新开发人员将难以通过这种方法获得她们期盼的反响。
AndrewMorton为有志向的内核开发人员提供了如下建议
所有内核开发者的第一个项目肯定应该是“确保内核在您可以操作的所有 机器上始终完美运行”。通常的方法是和其他人一起解决问题(这可能需 要坚持!),但就是如此——这是内核开发的一部分。
()
在没有显著问题须要解决的情况下,一般建议开发人员查看当前的回归和开放缺陷列表。从来都不缺乏须要解决的问题;通过解决这种问题,开发人员将从该过程获得经验,同时与开发社区的其他成员构建互相尊重。