论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2008-10-28 15:00 |只看该作者 |倒序浏览

（贴在这里，希望能有那么点作用。）

原文地址：http://linux.tar.bz/articles/2.6-development_process
--------------------

介绍linux内核的开发过程
由Paolo Ciarrocchi所写，2005年9月
http://paolociarrocchi.googlepages.com/

---- 概述 ----
linux内核开发过程是非常复杂的，并且没有很好地文档化。所以我决定怀着希望对它做些总结，这也是为了社区。2.6.x的内核是基本的稳定的版本，由Linus发布的。
最高的数字是最新的版本。
如果需要回归，或是严重的缺点被发现，那么一个-stable修正补丁将被发布(请看下面)，它在上面的基础版本之上。一旦一个新的2.6.x的基础内核被发布后，一个补丁是对前一个2.6.x内核的一个增量。

---- 2.6.x 系列内核 ----
2.6.x系列内核由Linus Torvalds来维护
它按照下面的步骤开发：
- 只要一个新的内核被发布，一个两周的窗口被打开，在这个期间，维护者可以发送大的不同给Linus，通常是-mm内核的补丁，一些周之后。
发送大的改变，建议使用GIT
(更多有关GIT的信息在http://git.or.cz/和http://www.kernel.org/pub/software/scm/git/docs/tutorial.html)
- 两周之后，一个-rc1的内核被发布，被允许的补丁是不包含新功能可能影响整个内核的稳定性的。请注意一个整个的新驱动(或文件系统)可能被接受，在一个-rc1之后。因为这样的一个改变不会引起回归。
- 一个新的-rc被发布，无论什么时候Linus认为当前的git(内核源码管理系统)树应该处于一个健全的状态，以便测试。目标是每周发布一个-rc内核。
- 过程一直被持续，直到内核被认为“准备好”，这个过程应该持续大概6周(每年应该发布6个内核)，通常包含4/5个rc版本。

有一系列工具用来测量内核的质量和性能。
一些例子：
- kernel-perf.sourceforge.net
复制过来的项目描述：
“我们是一个组织，是专注于linux内核的工程师，做linux内核方面的测试工作。为了跟踪性能，我们运行很大集合的测试，在linux内核的核心组件上(虚拟内存管理，I/O子系统，进程调度，文件系统，网络，设备驱动等)。测试在各种平台上运行，测试最新的快照的Linus的git开发树。
可理解的性能数据，来自我们的测试，将放在这里，方便访问。”
- bugzilla.kernel.org
这是官方的bugzilla实体，用来在线跟踪内核的bug。
用户被邀请来报告所有的bug，他们使用工具中遇到的。
但是，值得提到Andrew Morton在lkml上提到的话：
“没有人知道什么时候一个内核会被发布，因为它根据前面的bug状态来发布，并不根据之前构想的时间线。”

--- 2.6.x.y内核，a.k.a –stable ---
带有四个数字的内核版本是-stable的内核。他们包含小的关键的修改，可能是因为安全的原因，或者重大意义的回归，在一个提供的2.6.x内核上发现的。

这是用户要求的最新的稳定内核，并不是用来测试开发或实验性的版本。

如果没有2.6.x.y版本内核可用，最高版本的2.6.x内核是当前的稳定的内核。

2.6.x.y由“稳定”组来维护(stable@kernel.org)，几乎每周都发布。

规则用来决定什么样的补丁被接受，什么不被接受，到“-stable”版本的开发树中：
- 它必须很明显是正确的并经过测试的。
- 包括上下文，它不能大于100行
- 它只能修正一件事情
- 它必须修正了一个真实的bug，让人烦恼的(不是一个，“这可能是一个bug”，类型的事情)
- 它必须修正了一个引起编译错误的问题（而不是标记为CONFIG_BROKEN的事情），一个面向对象，一个挂起，数据损坏，一个真实的安全问题，或者一些“哦，那并不好”的问题。简短地说，就是关键的。
- 没有“理论的竞争条件”问题，除非有关这个竞争如何被攻破的解释。
- 它不能包含任何“琐细的”的修改在上面（拼写改变，空格清除，等）
- 它必须被相应的子系统维护者接受
- 它必须遵循Documentation/SubmittingPatches的规则

发送补丁到-stable树的过程：
- 发送补丁，在证实它遵守了上面的规则后，到stable@kernel.org。
- 发送者应该收到一个ack，说明补丁被接受到队列，或者一个nak，如果这个补丁被拒绝。回应可能需要一些日子，根据开发者的时间安排。
- 如果被接受了，补丁将被增加到-stable队列，供其他开发者评审。
- 安全补丁不要发送到这个名字，用这个代替security@kernel.org。

评审过程：
- 当-stable维护者决定评审一个过程时，补丁将被发送到评审委员会，补丁影响区域的维护者(除非发送者是区域的维护者)，和复制到linux-kernel的邮件列表。
- 评审委员会在48小时内ack或者nak这个补丁
- 如果补丁被评审委员会的一个成员拒绝，或者linux-kernel成员提出问题发对这个补丁，而维护者和成员没有认识到，补丁将被从队列中抛弃。
- 评审的最后，ack的补丁将被增加到最新的-stable发布版，一个新的-stable发布将开始。
- 安全补丁将直接从安全内核组接受到-stable中，不走前面的评审过程。

评审委员会：
- 由一系列内核开发者组成，志愿做这一事情，包括一小部分不是志愿的。

--- -mm内核 ---
这是由Andrew Morton发布的实验性的内核。

-mm分支提供一些被证明是新的特征和其他实验性的补丁
一旦一个补丁在-mm中证明它的价值，Andrew将把它发给Linus，在主线中讨论。

虽然鼓励补丁通过-mm树发给Linus，这并不是强制的。
子系统维护者（或者个人），有时候直接把补丁发给Linus，即使（或者之后）他们已经被合并和测试，在-mm中（或者有时候，没有之前在-mm中的测试）。

这一分支，持续流出，包含许多实验性的特征，很多的调试补丁，不适合主开发线的等。和最有实验性的分支，在文档中描述的。

这些核心不适合用在系统上，理应是稳定的。他们比其他的分支有更多的冒险（确定你有最新的备份-有一些实验性的内核，但更多的是-mm内核）。

这些内核增加所有其他实验性的补丁，也包含主线中的修改，也就是-git内核，在发布时间上可用的。

-mm内核并不在固定的时间上发布，当通常一些-mm内核在每个-rc内核间发布（1到3是常见的）。

--- -git 内核 ---
这是日常的Linus内核树的快照（在一个git仓库中管理，因此用了这个名字）。

这些补丁每天都发布并代表当前的Linus树的状态。他们比-日常内核有更多实验性，因为他们自动被产生，并且没有来得及去仔细看他们是否健全的。

我希望你喜爱这篇文章，我真的想表示感谢，对Tony Luck和Jesper Juhl的建议！！

这篇文章的一部分来自Jesper Juhl写的文档，你可以在这里找到：
http://sosdg.org/~coywolf/lxr/so ... pplying-patches.txt