轉自：https://blog.csdn.net/jasonactions/article/details/120776434
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 查看郵件列表
進入https://lore.kernel.org/ 可以看到所有子系統的郵件列表：
最開始通過郵件發送給maintainer的patch，可以通過 https://lore.kernel.org/lkml/ 進行查看，
後續經過郵件討論，最後形成的patch，先會進入到子系統的git倉庫中。
通過搜索作者名字，可以看到作者提交的patch，以及maintainer的兩次回覆。
點擊[PATCH] trace: Add trace any kernel object可以進入看到作者提交patch的郵件，可以看到郵件是發送給 [email protected] ，它也是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
————————————————
版權聲明：本文爲CSDN博主「HZero.chen」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/jasonactions/article/details/120776434