如何查看linux kernel邮件列表【转】

转自: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的邮件,可以看到邮件是发送给 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
————————————————
版权声明:本文为CSDN博主「HZero.chen」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/jasonactions/article/details/120776434

posted @ 2022-10-20 09:53  Sky&Zhang  阅读(516)  评论(0编辑  收藏  举报