1. 前言

本文主要总结浏览kernel patch的方法，以此希望促成自己养成阅读patch的习惯。用一个朋友的话说，这样才能更好的融入社区。

2. linux版本发展简介

2.1 史前时代（0.01~1.0）

版本更迭过程为：0.01 -> 0.02 -> 0.10 -> 0.11 -> 0.12 -> 0.95 -> 0.96 -> 0.97.x -> 0.98.x -> 0.99.x -> 1.0

2.2 奇偶时代（1.0~2.6.10）

• 版本号
  用 a.b.c 表示，其中 a 为主版本号，b 为次版本号，c 为修订号
• 版本号变更的原则
  发生重大改变时升级主版本号，发生非重大改变时升级次版本号；
  次版本号为奇数表示开发版，次版本号为偶数表示稳定版；
  稳定版和开发版在修订号上各自升级演进，开发版达到稳定状态时，发布下一个稳定版。
• 版本举例
  比如 1.0.x 在尽量不引入新功能的前提下不断升级；
  同时 1.1.x 在不断开发新功能的状态下不断升级；
  当 1.1.x 的开发到足够稳定时，转变成 1.2.x 成为稳定版；同时新的开发版 1.3.x 诞生……

2.3 快速演进时代（2.6.11～2.6.39）

• 版本号
  a.b.c.d 表示，其中 a 为主版本号，b 为次版本号，c 为主修订号，d 为次修订号。
• 版本号变更的原则
  主修订号 c 的升级既包括新特性引入，也包括缺陷修订（Bugfix），次修订号 d 的升级只包括 Bugfix

2.4 极速演进时代（3.0～5.x）

• 版本号
  版本号回归 a.b.c 表示法，a 为主版本号，b 为次版本号，c 为修订号。
  a 相当于之前的 a.b，新的 b 相当于之前的 c，新的 c 相当于之前的 d
• 版本号变更的原则
  次版本号 b 的升级既包括新特性引入，也包括缺陷修订（Bugfix），修订号 c 的升级只包括Bugfix。

3. Linux 内核的开发模式

在代码仓库管理上，有主线仓库（Mainline）、稳定仓库（Stable）、未来仓库（Linux-next）和子系统仓库（Subsystem）

上图来自用芯探核

3.1 子系统仓库（Subsystem）

绝大多数开发者所贡献的代码首先要接受子系统管理员（Maintainer）的审核，才能进入某个特定的子系统仓库；

3.2 未来仓库（Linux-next）

未来仓库的前身为 Andrew Morton 维护的 Linux-mm，代码变更在进入下一版主线内核之前先到达这里，类似于奇偶时代的奇数版本（开发版），有的也直接进入主线仓库。

3.3 主线仓库（Mainline）

主线仓库是最重要的仓库，其升级规则是在次版本号上面升级演进，两个正式版之间会发布若干个候选版（RC 版），如：
3.0 ->3.1-rc1 ->3.1-rcN ->3.1 -> 3.2-rc1 -> ……

某一个正式版和下一个候选版之间的时期叫做合并窗口期，比如 3.0 至 3.1-rc1 之间就是 3.1 的合并窗口。
只有在合并窗口里面才允许增加新特性，其他阶段只允许缺陷修订（Bugfix）。
也就是说，如果开发者想让某个新特性进入到 3.1 内核，那么必须保证在 3.1-rc1之前进入，否则就只能等待 3.2 的合并窗口了
二次审核通过以后，最后将进入主线仓库（偶尔也有跳过未来仓库，从子系统仓库直接进入主线仓库的情况）。
代码进入了主线内核，就相当于达到 RC 状态或者 Final 状态。

3.4 稳定仓库（Stable）

稳定仓库基于主线仓库的正式版产生，在修订号上面升级演进，如：
3.0 ->3.0.1 -> 3.0.2 -> 3.0.3 -> 3.0.N -> ……
3.1 -> 3.1.1 -> 3.1.2 -> 3.1.3 -> 3.1.N ->……
稳定仓库的代码变更全都是缺陷修订（Bugfix），不引入新的特征

4. 跟踪内核patch

如下以trace子系统提交的一个patch为例，进行跟踪，学习内核邮件沟通的过程，同时介绍patch的流动路径。

4.1 查看邮件列表

进入public-inbox listing 可以看到所有子系统的邮件列表：

最开始通过邮件发送给maintainer的patch，可以通过 linux-kernel.vger.kernel.org archive mirror 进行查看，
后续经过邮件讨论，最后形成的patch，先会进入到子系统的git仓库中。

通过搜索作者名字，可以看到作者提交的patch，以及maintainer的两次回复。

点击[PATCH] trace: Add trace any kernel object可以进入看到作者提交patch的邮件，可以看到邮件是发送给 rostedt@goodmis.org ，它也是trace子系统的maintainer，通过MAINTAINERS文档也可以看到rostedt不仅维护了trace子系统，还维护多个子系统，如：PRINTK，RCUTORTURE TEST FRAMEWORK，READ-COPY UPDATE (RCU)， SCHEDULER， SLEEPABLE READ-COPY UPDATE (SRCU)，TRACING MMIO ACCESSES (MMIOTRACE)，VSPRINTF，绝对的大神！
接下来我们可以看下这个patch的大致内容：

Introduce a method based on function tracer and kprobe event
to trace any object in the linux kernel.
Usage:
When using the kprobe event, only need to enable trace_object,
we can trace any function argument or the return value. When
the object passes through a function, it can be traced.

主要是基于function tracer和kprobe event引入了一个新的trace方法，可以跟踪某一个内核对象的生命周期，途经了哪些函数路径，不得不说，预感到这可能对于我们研究内核会很有帮助。比如我们通过观察一个page的执行流来研究内存管理方面。跟踪request或bio来研究IO子系统等。

接下来我们看下maintainer的第一封回复：
Re: [PATCH] trace: Add trace any kernel object

这里maintainer的回复显示对这个patch还是很感兴趣的，希望一同完善这个patch。

待续。。。

参考文档

用"芯"探核-基于龙芯的Linux内核探索解析

Linux内核版本新功能

Kernel coverage at LWN.net