针对这些问题，我个人是这样理解的。如果没有接触过大型软件项目，可能分析Linux内核代码是一个很好的积累大型项目经验的机会（确实，Linux代码是我目前接触到的最大的项目了！）。如果你对计算机底层了解的不够透彻，那么我们可以选择边分析边学习的方式去积累底层的知识。可能刚开始分析代码的进度会稍显迟缓，但是随着知识的不断积累，我们对Linux内核的“业务逻辑”会逐渐明朗起来。最后一点，如何从全局的角度把握分析的源码，这也是我想与大家分享的经验。
三、内核源码分析方法
第一步：资料搜集
从人认识新事物的角度来讲，在探索事物本质之前，必须有一个了解新鲜事物的过程，这个过程是的我们对新鲜事物产生一个初步的概念。比如我们想学习钢琴，那么我们需要先了解弹奏钢琴需要我们学习基本的乐理、简谱、五线谱等基础知识，然后学习钢琴弹奏的技巧和指法，最后才能真正的开始练习钢琴。
分析内核代码也是如此，首先我们需要定位要分析的代码涉及的内容。是进程同步和调度的代码，是内存管理的代码，还是设备管理的代码，还是系统启动的代码等等。内核的庞大决定着我们不能一次性将内核代码全部分析完成，因此我们需要给自己一个合理的分工。正如算法设计告诉我们的，要解决一个大问题，首先要解决它所涉及的子问题。
定位好要分析的代码范围，我们就可以动用手头的一切资源，尽可能的全面了解该部分代码的整体结构和大致功能。
这里所说的一切资源是指无论是Baidu、Google大型网络搜索引擎，还是操作系统原理教材和专业书籍，亦或是他人提供的经验和资料，甚至是Linux源码提供的文档、注释和源码标识符的名称（不要小看代码中的标识符的命名，有时它们能提供关键的信息）。总之这里的一切资源指的就是你能想到的一切可用资源。当然，我们不太可能通过这种形式的信息搜集获得所有的我们想要的信息，我们只求尽可能全面即可。因为信息搜集的越全面，之后分析代码的过程能使用的信息就更多，分析过程的困难就会越小。
这里举一个简单的例子，假定我们要分析Linux的变频机制实现的代码。目前为止我们仅仅是知道这个名词而已，透过字面含义我们可以大致猜测它应该和CPU的频率调节相关。通过信息搜集，我们应该能得到如下的相关的信息：
1．CPUFreq机制。
2．performance、powersave、userspace、ondemand、conservative调频策略。
3．/driver/cpufreq/。
4．/documention/cpufreq。
5．P state和C state。
……
分析Linux内核代码如果能搜集到这些信息，应该说是非常“幸运”了。毕竟有关Linux内核的资料确实不如.NET和JQuery那么丰富，不过这相比于十数年前，没有强大的搜索引擎，没有相关的研究资料的时期应该称得上是“大丰收”时代了！我们通过简单的“搜索”（可能会花费一到两天的时间吧），甚至找到了这部分代码所在的源码文件目录，不得不说这样的信息简直是“价值连城”！
第二步：源码定位
从资料搜集中，我们“有幸”找到了源码相关的源码目录。但是这并非意味着我们的确就是分析这个目录下的源代码。有时我们找到的目录有可能是分散的，也有时我们找到的目录下有很多和具体机器相关的代码，而我们更关心的是待分析代码的主要机制，而非与机器相关的特化代码（这样更有助于我们理解内核的本质）。因此，我们需要对资料中涉及代码文件的资料进行仔细甄选。当然，这一步也不太可能一次性完成，谁也不能保证一次就能选择出所有待分析的源码文件而且一个不漏。但是我们也不必担心，只要我们能抓住大多数模块相关的核心源文件，通过后期对代码的具体分析，就很自然的把它们全部找出来。
回到上述的例子中，我们认真的阅读/documention/cpufreq下的文档说明。目前的Linux源码会把模块相关的文档说明保存在源码目录的documention的文件夹下，如果待分析的模块没有文档说明，这多少会增加定位关键源码文件的难度，但是不会导致我们找不到我们要分析的源码。通过阅读文档说明，我们至少能关注到/driver/cpufreq/cpufreq.c这个源文件。通过这个对源文件的文档说明，结合之前搜罗到的调频策略，我们很容易关注到cpufreq_performance.c、cpufreq_powersave.c、cpufreq_userspace.c、cpufreq_ondemand、cpufreq_conservative.c这五个源文件。所有涉及的文件都找完了吗？不用担心，从它们开始分析，迟早能找到其他的源文件。如果在windows下使用sourceinsight阅读内核源码的话，我们通过函数的调用和查找符号引用等功能，结合代码的分析可以很方便的找到另外的文件freq_table.c、cpufreq_stats.c和/include/linux/cpufreq.h。