聊聊怎么阅读内核源码的
The following article is from 开发内功修炼 Author 张彦飞allen
来源 | 开发内功修炼（ID：kfngxl）
经常在后台收到读者的交流，Linux 源码那么庞大，飞哥你是如何读的呢？由于问这个问题的太多，我想有必要专门写一篇文章聊一聊。
首先，我先说一点，其实我本人不是搞内核相关工作的。我和大多数同学都一样，从事的也是应用层上的开发，负责的是后端模块。
那我为什么要研究源码这个之前我说过，是因为我在多年的工作中遇到的很多问题都是底层相关的。不深入底层看一看，感觉永远是在隔靴挠痒，永远理解不到问题的本质。（这里说的底层其实也不只是包括 Linux 内核，还包括一些硬件的组成原理啥的）。
飞哥走过的弯路
虽然咱们今天的主题是源码，不过我并不建议你一开始就陷入到源码里，这也是我走过的弯路。
在我刚开始想深入挖掘网络性能的时候，我买来了《深入理解 LINUX 内核》《深入理解 Linux 网络技术内幕》等几本书。这本书里介绍了内核中各个组件，如网卡设备、邻居子系统、路由等，把相关源码都讲了一遍。
我啃了好长时间，但结果是看完以后感觉还是一团浆糊。尤其是到了工作中具体的一个实际问题的时候，发现根本还是理解不了网络模块到底是怎么运作的。比如一个包到底是如何从网卡到应用程序中的，这些书看半天还是弄不明白这个问题。就更别提后续搞一些网络优化的事情了。
到了后来，我改变了战术，才算是柳暗花明又一村，找到了真正正确、高效的方法。
产生问题
我所找到的正确方法就是，以工作中的实际问题为核心。
回头想想我们看源码的目的是啥呢，是要把 Linux 搞明白？我想不是，把 Linux 搞明白只是途径，而我们的真正目的是为了提高我们手头的工作。
比如，我想观察我的服务中 Linux 的收包的过程是否出现了问题，以及想尝试在这个接收过程中都有哪些优化方法。基于这个工作中的需求出发，然后我就四处开始翻资料，打算要把 Linux 是如何接收和处理一个网络包彻底搞搞清楚。包括我之前看过的源码的书，也查了好多网络上的文章。最后终于摸出了个十之八九，总结出了图解Linux网络包接收过程。
再比如我手头的项目中很多地方需要维持长连接，那么我就想搞明白一台 Linux 服务器最多能支撑多少个 TCP 连接？这种问题更是，几乎没有任何书，任何资料，任何文章能给一个让我满意的答案。这个时候光翻源码，看网络上的技术文也是远远不够的，我动手写了不少测试代码，亲手进行实践。写出了
漫画|一台Linux服务器最多能支撑多少个TCP连接？ 漫画 | 理解了TCP连接的实现以后，客户端的并发也爆发了！ 百看不如一练，动手测试单机百万连接的保姆级教程！
再比如有同学问了我，127.0.0.1 是如何进行网络包收发的，和跨机 IO 相比，能节约哪些开销？
但其实我所关注的点并不都在内核源码上。比如在我前期的一些文章里，我想弄明白访问内存的速度。我研究了 L1、L2、L3。还调研了内存的工作原理。随后发现了内存在随机 IO 的时候也是会比顺序IO要慢几倍的。后来我想搞明白固态硬盘和机械硬盘的速度差异，我又去分析了固态硬盘的物理构成。而且所有的这些我都搭配了实际的性能测试。
今天的重点并不是给大家介绍这些文章，我想表达的意思是，产生问题非常重要。
这些问题最好是能和你手工工作相关，因为这样你后期才能在工作中进行应用和提升。我觉得只有有用的技术，才是真正有价值的技术。至于说硬件组成原理，内核源码，极客时间上的一些优秀的网课，都是解决这些问题是的工具而已。
源码阅读方法
在解决问题的时候，内核源码确实是很重要的一块，也是我们今天介绍的主题。看代码我觉得有两个方法，可以用地毯式的轰炸和精确制导来类比。
地毯式轰炸
地毯式轰炸就是不管三七二十一，把内核所有的源码全部硬啃一遍。各个组件都进去看一看，了解了解。
除非你本身就是搞内核相关的工作的，否则我是不推荐大家去把内核源码通读一遍的。这也是我前面和大家讲过的我走的弯路。因为这样搞有如下的缺点：
第一，我们大部分的读者都是已经工作了的同学。你没有学生时代那么大块的时间去整块整块的啃。
第二，即使你啃完了，你和手头的工作还是联系不起来。前面我说过，我啃完了《深入理解 Linux 网络技术内幕》，仍然连网络包是如何从网卡到用户进程里的还是没搞明白。
这就好比在战场上，动用大量的武器弹药进行狂轰滥炸。这种方法非常浪费弹药，而且很有可能还没有炸到关键的碉堡。
精确制导
这个是我所推荐的方法。前面不是说过，我们一定要先产生一个问题么。那么我们看源码的目标就是要精确制导消灭这个对象。
等我们进入到内核源码里的时候，你会发现这里面逻辑关系错综复杂。如果每一个逻辑你都想钻进去弄个明白，最后可能就是累死在内核源码的迷宫里了。
所以我们在看源码的时候，要时刻牢记我们要消灭的问题是啥。如果某段逻辑和你要解决的问题无关，那就直接绕过去，绕过去，不要恋战！
你在我的文章里应该也能发现，我虽然会贴内核源码，但是绝大部分的源码都包含省略号。这些就是我觉得和当前主题无关的源码，所以我都躲着它们走。
比如在介绍内核发送数据过程的时候，我介绍到 inet_sendmsg，我是这样展示的的。
//file: net/ipv4/af_inet.c
int inet_sendmsg(......)
{
......
return sk->sk_prot->sendmsg(iocb, sk, msg, size);
}
而实际上，内核的源码长的是这样的。
int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
size_t size)
{
struct sock *sk = sock->sk;
sock_rps_record_flow(sk);
/* We may need to bind the socket. */
if (!inet_sk(sk)->inet_num && !sk->sk_prot->no_autobind &&
inet_autobind(sk))
return -EAGAIN;
return sk->sk_prot->sendmsg(iocb, sk, msg, size);
}
省略掉的这段逻辑我认为和我要解决的问题关系很小，所以都被我绕开了。
每次通过这种方法解决掉你的一个问题的时候，你就以点状的形式在洞穿理解了内核某一片的逻辑。等当你解决掉很多问题的时候，点会逐渐的连成面。这时候反而能得到更全面的，更深刻的理解。
小结一下，要时刻记住要消灭的问题是啥，无关的代码能绕开就都绕开。
吾生有涯，而知无涯，我们只挑对我们有用的进行学习。
一些工具
这里再介绍几个我看源码时用到的工具。
Linux 源码
可能有些同学还不知道到哪儿去下，这里我把地址列出来。
下载地址：https://mirrors.edge.kernel.org/pub/linux/kernel/
不过有同学表示上述地址有的时候访问不了，所以我也把我文章中用到的 3.10 的源码放到网盘里了。
链接：https://pan.baidu.com/s/144BlNXwrY3iAxKRbX7oHeg
提取码：iqrr
在线源码
如果你只是临时想看某一个函数，这个时候可能没有必要去下载完整的源码。那用它就再合适不过了。bootlin 网站：http://elixir.bootlin.com/
假如我想搜 __alloc_skb 这个函数是在哪儿定义的，在哪儿被使用的。那就在这个网站的右上角搜索这个函数名。结果如下：
VSCode
我看源码习惯用它，跳转啥的都比较方便。安装啥的我就不介绍了，大家自己去搜。我这里介绍几个我常用的用法
查找函数声明、定义、引用
这个是最常用的，只需要在函数名上点右键，在菜单里就选择相应的功能点就可以了。
返回上一次浏览位置
在跳转了几次以后，你很有可能想回到原来函数的位置继续查看下面的代码。这个时候只需要用快捷键即可，Mac 下使用 ctrl + -，Windows 下使用 Alt + ← 。按几次，就返回几次。
打开指定文件
Linux 的目录多，而且目录下的文件也太多。有的时候即使你知道源码在哪个目录下，可能还是得翻半天才能找到。如果你明确知道源码文件的位置，那么可以直接打开它就行。
比如 tcp 的关键接收入口函数 tcp_v4_rcv，它在 net/ipv4/tcp_ipv4.c 这个文件下（我的文章里我尽量会把每一个函数所处的位置都标清楚）。
那么如果你想快速打开这个函数，那么你按下快捷键 cmd + p（Windows 下 ctrl + p）。直接输入 tcp_ipv4.c 这个文件名就可以了。
我常用的就这么几个，如果想看所有的快捷键，那就 cmd + k,接着再 cmd + s （Windows 下是 ctrl + k, ctrl +s）可以查看到所有的快捷键。
总结一下
不知道大家有没有听说过“势 道 术”。
势是未来发展的大势 道是事物背后的规律 术是技术层面的操作方法
很明显这三个层次里越靠前是越牛的。我这里套用一个这个概念，今天其实给大家分享了两个层次的东西。
在术的层面，我分享了我是怎么看 Linux 源码的，在哪儿下载源码，用的什么工具，按的什么快捷键。不过我觉得这个不是最重要的。
在道的层面，学习技术最主要的目的是要能解决我们手头工作中的问题，明确你要解决的问题之后，精确制导，把所有的精力都围绕着这个问题进行。至于说底层的硬件组成原理也好，内核源码也罢，极客时间上的优秀网课，都只不过是我在解决这些问题是的工具而已。不要本末倒置了，学以致用，学的目的就是用。
有的读者和我反馈说，很多知识自己也不是没看过，但是看过就忘。其实我觉得这里面可能主要的原因就是没有和手头的工作结合起来，没有用起来。如果你用这些知识解决过自己的工作中的实际问题，甚至是有过性能优化之类的经验，我想这样你学过的东西是忘不了的。