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）
| 仓库名称 | maintainer | Git 仓库地址 |
| Subsystem | e.g. rostedt | e.g. https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git |
| Linux-next | Stephen Rothwell | git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git |
| Stable | Greg Kroah-Hartman 等 | git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git |
| Mainline | Linus Torvalds | git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git |
上图来自用芯探核
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内核探索解析