|
mainline:
|
3.18-rc1
|
2014-10-20
|
[]
|
[]
|
[]
|
|
[]
|
[]
|
|
|
stable:
|
3.17.1
|
2014-10-15
|
[]
|
[]
|
[]
|
|
[]
|
[]
|
[]
|
|
stable:
|
3.16.6
|
2014-10-15
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
3.14.22
|
2014-10-15
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
3.12.30
|
2014-10-08
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
3.10.58
|
2014-10-15
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
3.4.104
|
2014-09-25
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
3.2.63
|
2014-09-13
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
longterm:
|
2.6.32.63
|
2014-06-18
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
[]
|
|
linux-next:
|
next-20141022
|
2014-10-22
|
|
|
|
|
|
[]
|
|
Linux 内核是由多个开发者以分散型的模式进行开发的。 这里出现的“ 分散型 ” 是指多个衍生源码树同时存在。下面将简单介绍一些具有代表性的源码树及其地位。
Linus 树
最具有代表性的源码树应属 Linux 内核的最初创始人 ——Linus Torvalds 所管理的Linus 树。新版本 Linux 内核的发布,就意味着 Linus 树的源代码被贴上了新发布版本的标签。 到 2011 年为止,Linux 内核的版本号一直是用 2.6.x 这样的三个数字来表示的（Linux 2.6.39 的下一版本将是 Linux 3.0）.Linus 树一直被认为是 Linux 内核源代码的“ 根源 ” 因此一旦其发布了新版本, 其他的开发树就会将自己独特的开发成果移植到这个版本上,在此基础上再次进行开发。Linus树由于其“根源”的地位而称为主线(mainline)。
一旦发布新版本 Linus 树, 就会立刻打开一个“ 合并窗口 ” merge window) 接受下一版本需要作出的改变。 合并窗口将开启约两周时间。 合并窗口关闭后, 就会发布下一版本的候选版, 即所谓的“rc 内核 ” （rc 是 release candidate(发布候选)的缩写）。 从 rc 内核发布后到下一版本发布的期间为测试期,这一期间基本只接受关于bugfix 的修改。rc 版内核每隔约一周时间会依次推出 rc1、rc2...... 当 Linus 判断其质量已经达到可以发布的水平时, 就会作为新版本发布。 按照最近的实际情况来看, 基本上在 rc6 ~ rc9 左右就会发布新版本, 也就是说 Linux 内核每隔 2 ~ 3 个月就会发布新版本。 新版本发布后, 又会打开下一版本的合并窗口, 然后对rc 版进行测试。
Linux 内核就是按照这样的周期来开发的。
linux-next 树
这是一个为发布将来的版本而积累新代码并进行测试的源码树, 主要由 Stephen Rothwell 等人进行管理和运营。 原则上要添加新功能或者进行安装配置时, 首先要在linux-next 树中进行测试,在确认各自之间可以兼容之后再添加到 Linus 树内。
stable 树
这是一个主要只针对过去发布的内核版本进行 bug 修改, 使其更加稳定的树, 由 Greg Kroah-Hartman、Chris Wright 进行维护管理。 这个树的版本号是在 Linus 树的版本号后面加一位数字来表示。 针对某个 Linus 树版本的稳 定(stable)版维护一般持续 6 个月左右,但也有持续更久的。
开发树
Linux 内核可以说是各种功能的集合体。 例如内存管理、 文件系统、 网络、 各种设备驱动程序、CPU 架构固有部分等。 这些功能部分称为“ 子系统 ” 各子系统分别在不同的源码树中进行开发。 在开发、 修改过程中也有一些不属于特定子系统的内容, 这些内容首先会被发送到 Andrew Morton 管理的 mm 树( 准确地说是 mmotm :mm on the moment ,补丁包的缩写) 这样的源码树统称为“开发树”。在各开发树中开发出的源代码在经过 linux-next 中的测试后再植入 Linus 树。开发树的数量多如繁星。 如果哪天你因为想要开发某个功能而在手边的源代码上进行了修改,这也可以说是一个“开发树”。Linus 树、开发树等作为所有树的根源,也称为“upstream” 即“上游” 但这是广义上的叫法,有时也仅指最上游的 Linus 树。
发布版内核
最后要介绍的是发布版内核(distribution kernel) 应该有很多人使用的都是作为 Linux。发布版的一部分发布的内核。 这些来源于发布版的内核几乎都是在 Linus 树或 stable 树内核的基础上进行发布版特有的扩展和 bug 修改而得到的。 像这样添加了发布版特有的修改,并作为发布版的一部分发布的内核,就称为“发布版内核”。
一、Linux内核版本类型及patch简介：
1) 2.6.x为基础版本，patch位置：
2) 2.6.x.y为2.6.x基础版本之上派生出来的修正版本，称为-stable内核版本，patch位置：
3) 2.6.x.rcN(Release Candidate)内核，是在2.6.(x-1)之上派生出来的之后版本的侯选版本；此种内核不稳定，发布的时候表示可以用来测试了；
例如对2.6.21加了新功能后派生出2.6.22-rc1，patch位置：
4) git内核是每日内核树的快照，此类型比rc内核更不稳定，从基础版本或rc版本派生出来；
例如2.6.26-git1，2.6.26-rc9-git2，patch位置：
5) mm内核是专门针对内核的mm模块维护的版本，类似于git版本从基础版本或rc版本派生出来；
例如2.6.21-mm2, 2.6.21-rc2-mm1，patch位置：
不同类型内核的patch名称在前面加上“patch-”（mm内核除外，直接用的版本号），例如：patch-2.6.21,
patch-2.6.21.7, patch-2.6.26-git1, patch-2.6.26-rc9-git2, 2.6.21-mm2,
2.6.21-rc2-mm1
二、内核补丁类型
1) 增量补丁
同一类型的版本的补丁是用本版本对相邻的前一个版本制作的。
例如，patch-2.6.21是对2.6.20做的补丁，patch-2.6.22是对2.6.21做的补丁，这就是增量补丁。
2.6.x基础版本内核，采用的是增量补丁。
2) 非增量补丁
与增量补丁相反，是基于某一固定版本制作的补丁，而非相邻的前一个版本。
例如，patch-2.6.21.3是2.6.21.3版本相对于2.6.21基础版本做的补丁，patch-2.6.21.4是2.6.21.4版本相对于2.6.21基础版本做的补丁，也就是说2.6.21.4与2.6.21.3之前没有补丁可用。
rc内核，git内核和mm内核都是非增量补丁，都是相对于当前基础版本或rc版本制作出来的补丁。
另外，对于rc内核，git内核，相应的patch目录下面有inc目录中，包含有增量补丁。
三、使用patch命令为内核补丁
1.现有基础内核版本2.6.12，想转成2.6.12.6内核stable版本，应该怎么办？
a) 去下载patch-2.6.12.6；
b) Linux shell下面，cd到2.6.21内核源文件根目录(linux-2.6.21)，将patch-2.6.21.7也放在本目
录(命令执行的当前止录)，执行patch命令：：patch -p1 < patch-2.6.21.7
(p1的意思是忽略patch文件（即diff文件）内容中的第一个路径)
c) 打完补丁后，即变成了2.6.21.7的内核了，如果想回退至2.6.21基础版本，执行如下命令即可：
patch -R -p1 < patch-2.6.21.7
(-R的参数意思表示回退这个patch)
2.现有基础内核版本2.6.21，想转成2.6.23.1内核stable版本，应该怎么办？
a) 同1中下载patch-2.6.22, patch-2.6.23, patch-2.6.23.1文件，并设置执行路径和环境；
b) patch -p1 < patch-2.6.22 变成了2.6.22
patch -p1 < patch-2.6.23 变成了2.6.23
patch -p1 < patch-2.6.23.1 变成了2.6.23.1
c) 回退操作
patch -R -p1 < patch-2.6.23.1 变成了2.6.23
patch -R -p1 < patch-2.6.23 变成了2.6.22
patch -R -p1 < patch-2.6.22 变成了2.6.21
3.现有基础内核版本2.6.21-git2，想转成2.6.22-rc1-mm2内核stable版本，应该怎么办？
a) 同1中下载patch-2.6.21-git2, patch-2.6.22-rc1, 2.6.22-rc1-mm2文件，
并设置执行路径和环境；
b) patch -R -p1 < patch-2.6.21-git2 变成了2.6.21
patch -p1 < patch-2.6.22-rc1 变成了2.6.22-rc1
patch -p1 < 2.6.22-rc1-mm2 变成了2.6.22-rc1-mm2
c) 回退操作
patch -R -p1 < 2.6.22-rc1-mm2 变成了2.6.22-rc1
patch -R -p1 < patch-2.6.22-rc1 变成了2.6.21
patch -p1 < patch-2.6.21-git2 变成了2.6.21-git2
四、总结
diff -urN src dst > patch 生成patch
patch -p[0-n] -s < patch 使用patch，-s参数即silent，表示终端无信息输出
patch -Rp[0-n] < patch 回退patch
patch -p[0-n] --dry-run < patch 只显示运行结果，不实际生效
另外，当patch命令检测到冲突时会弹出提示，还会生成一些.rej文件，可查看.rej文件来手动修改。
