我们在编译Linux内核时，往往在Linux内核的顶层目录会执行一些命令，这里我以RK3288举例，比如：make firefly-rk3288-linux_defconfig、make menuconfig、make firefly-rk3288.img、make zImage等等。先不管这具体的含义，首先提出几个疑问：
（1）Linux内核如此庞大（几万个文件），目录又分为很多层，它是如何将各层目录下的文件关联起来的？
（2）Linux支持如此多的架构（X86、ARM、AVR、mips等等），为何我们在使用某一架构的芯片，比如RK3288时，其他架构的代码不会被编译？并且同为ARM架构下的其他系列SOC架构相关的代码不被编译？
（3）在编译内核前，执行命令：make menuconfig的意义为何？
（4）编译内核时，执行命令：make zImage的意义为何？
（5）Linux内核中各层目录下的Makefile文件和Kconfig文件是如何编写的。
个人认为，当理解了解决了以上的几个问题，那么本文题目的疑问就自然而然的解决了。以下笔者来一一回答这个问题：
问题1.Linux内核如此庞大（几万个文件），目录又分为很多层，它是如何将各层目录下的文件关联起来的？
关于此问题，如果要准确的回答，估计只有真正的大神才能回答了，这里只讲自己的理解。Linux内核源码的代码管理是非常科学的，在Linux内核源码的顶层目录下，分配了相应的目录，在对应的目录下，代表这就一些功能或者是属性的集群，这样就实现了模块化，便于管理，比如arch目录与平台架构相关、include目录存放着大量的内核头文件、drivers目录存放着各种驱动代码，比如显卡、网卡、USB总线、PCI总线等等、kernel目录存放着支持体系结构特有的诸如信号量处理和SMP之类特征的实现、mm目录存放着体系结构特有的内存管理程序的实现等等；然而在各个子目录下，又会进行细分，比如arch目录下，就存在和x86架构相关的目录x86、与ARM架构相关的目录arm、与MIPS目录相关的目录mips等等，以此类推。所以这就构成了一颗树形结构。
学习过数据结构的童鞋应该知道，对于一棵非标准树，还是有办法将其进行遍历的，只是算法比较复杂而已。那么在Linux内核源码的这棵树，就是通过Kconfig文件建立各层子目录之间的连接，通过Makefile文件来选择各个目录下的对应的文件是否被编译，而.config文件就像是作为总控制台吧，控制着Makefile文件去编译指定的程序代码文件（主要是C和汇编）。而这一切控制关系是由Kconfig文件建立起来的。
在我理解而言，这其实就是在遍历树形结构时，用的一种方法，即指路法。每当我们在某个陌生的地方问路时，假设从A地到E地，情景通常如下：
通常我们也会按照路人的回答，很准确的就找到了目的地E，所以，在程序中或者代码架构中也是一样的。所以在Linux内核源码中，.config文件就相当于路人，而Kconfig就为问路的人，而Makefile就为两只脚了，听指令干苦力的货！嘿嘿！
问题2.Linux支持如此多的架构（X86、ARM、AVR、mips等等），为何我们在使用某一架构的芯片，比如RK3288时，其他架构的代码不会被编译？并且同为ARM架构下的其他系列SOC架构相关的代码不被编译？
关于这个问题，其实和我们在编译Linux内核时，执行的命令：make firefly-rk3288-linux_defconfig或者make menuconfig有关了，执行以上两个命令的目的是为了生成.config文件。往往我们执行命令make menuconfig只是为了修改一些驱动模块和要编译的一些程序，往往我们是不会去选择架构相关的，比如说，自行的去选择RK3288这颗SOC，再去选择基于Firefly平台的板卡，其实这也是可以的，只要你开心，都可以自行在菜单里面选择，但是通常我们不会这样，我们通常是先执行make firefly-rk3288-linux_defconfig生成了一个基于Firefly平台的RK3288相关配置的.config文件，然后再执行命令make menuconfig来选择一些模块代码进行编译，这样做的好处就是减少了很多工作量。当然，存在一个问题是，假设需要编译的内核不支持现有的开发板怎么办？比如从官网下载下来的原始Linux内核源码，只支持RK3288这颗SOC，但是并没有急于Firefly开发的这款RK3288的开发板，怎么办呢？这涉及到了Linux内核的移植，在此不作过多的叙述，提醒一点的是，可以找一块基于RK3288这颗SOC的开发板的配置（在官方发布的初始Linux内核源码中，每支持一款SOC，基本上都会对于的支持一款官方开发板作为参考），进行移植和模拟，后生成一个类似于firefly-rk3288-linux_defconfig的配置文件，用它来生成基本的.config文件。
清楚了以上的关系，在根据问题1的原因，就不难理解了。没错，就是基于firefly-rk3288-linux_defconfig文件生成了基础的，默认的.config配置文件，此文件的内容就包含了架构相关的东西，所以在进行Linux内核源码的编译时，根据.config文件的基本配置，寻找架构相关的代码进行编译和设备相关的代码进行编译。总之一起而已.config这个控制台为准。
问题3.在编译内核前，执行命令：make menuconfig的意义为何？
其实这个问题在前两个问题中基本上都回答了，make menuconfig就是以菜单的形式打开内核源码的树形结构，然后程序员在默认配置的基础上自行配置和选择需要编译的模块代码。
其实能做这个工作的命令有很多，比如：
•make config：基于文本的为传统的配置界面，太复杂，不直观，不推荐使用。
•#make xconfig：基于图形窗口模式的配置界面，直观明了，Xwindow界面下推荐使用。
•make oldconfig：如果只想在原来内核配置的基础上修改一些小地方，会省去不少麻烦，可以使用。
•make menuconfig：基于文本选单的配置界面，直观明了，字符终端下推荐使用。
大概好像这几种吧，其实还有一种就是，手动修改.config文件，呵呵！相信基本上没人会去干这种事的。
问题4.编译内核时，执行命令：make zImage的意义为何？
通常在编译时，都是执行这个命令或者执行make uImage命令进行编译的。意义为何呢？其实是生成名为zImage或uImage的内核镜像。当然，有人在疑问了，在编译Firefly的RK3288开发板时，执行的命令是make firefly-rk3288.img ，而不是上面的任何一个，其实这是Firefly修改过的方法了，其实说白了也就是一个名字而已。这个不要太过纠结，想具体了解的话，答案就在Firefly提供的内核源码内。
执行编译命令后，通过.config文件、Kconfig文件和Makefile文件，就可以有规律有选择的去编译源代码了。
问题5.内核中各层目录下的Makefile文件和Kconfig文件是如何编写的。
其实前面的4个问题只是基础的铺垫，这才是重点，但是这里必须依赖于前面的原理。
首先我们先确定一点，在Linux内核源码的各层目录下。都存在一个Kconfig文件和一个Makefile文件，.config文件存在顶层目录。如下图：
上图基本上可以证明一切了。
为了更好的诠释，我在drivers目录下创建了一个my_dr目录，主要存放我自己编写的内核驱动代码，此目录下的其他目录都是我编写的驱动代码，现在需要将它们连接起来，当执行make menuconfig命令时，能够找到我自己编写的内核驱动代码。在这里以一个hello程序举例。
那么到底该如何做呢？•••••••••两字：“模仿”！
如下图：
上图中就是我要举例的目录层了，hello目录里为hello.c程序；my_dr目录里为我想把我自己写的驱动程序存放的目录；drivers目录为Linux内核驱动目录；firefly-rk3288-kernel目录为Linux内核源码顶层目录。所以按照前文的推断，在每一层目录下都会存在一个Makefile文件和一个Kconfig文件。下面从底层hello到drivers目录各层Makefile文件和Kconfig文件分析。
（1）hello目录
如上图，左边为Makefile文件，右边为Kconfig文件。对于Makefile文件，如果变量CONFIG_HELLO为真或假，则判断这是否将目录下的hello.c文件编译为hello.o文件。CONFIG_HELLO变量的值来自于.config文件的配置。.config的配置又来自于通过Kconfig文件的显式选择（就是通过菜单选择）。再看Kconfig文件，如下图：
Config为配置关键字；HELLO为配置项；tristate为三态选择器，此关键字在为上层提供菜单配置时，有三种选择，分别是不编译、编译成内核镜像和编译成模块驱动，除了这个关键字，还有另一个bool，这个不难理解，即为布尔类型，西游两种选择，编译或者不编译；help为帮助提示。这基本上是比较经典的格式了。所以通常在进行编写这样的配置时，通常的做法是参考Linux内核源码中存在的Kconfig文件和Makefile文件，然后模仿他们的格式进行编写。
（2）my_dr目录
如上图，即为mu_dr目录下的Makefile文件和Kconfig文件的内容了。对于Makefile文件，一句话指引找到hello目录。而对于Kconfig文件，因为my_dr目录下可能要存在很多驱动程序，所以必须要建立好一个菜单，进行对各个驱动程序的选择，所以第1行代码就算建立名为my Drivers的菜单；第5行代表可以在相对路径drivers/my_dr/hello/Kconfig找到Kconfig资源（注意，这里的路径是相对于Linux内核源码的顶层目录的）。后的第7行表示使用关键字endmenu结束文件。
（3）drivers目录
如上图，即为drivers目录下的Makefile文件和Kconfig文件了。还是一样的，在Makefile文件中添加洗衣歌资源的菜单目录路径；而在Kconfig文件中，还是添加此目录下的资源的Kconfig文件的路径。就这样配合使用。而且，基本上在这两个文档中，可以直接看到很多的参考示例，直接参考即可！其实有一个疑问是，在Makefile文件中，比如第158行，如下图：
存在变量CONFIG_GATOR，这是为啥嘞？其实是这样的，这表示如果想想在菜单中显示选择关于gator的目录菜单，就必须依赖于变量CONFIG_GATOR的值为y，这样才能在使用make menuconfig命令时，才能看到gator目录下的菜单，而CONFIG_GATOR变量则是在gator目录的上层，依赖于某些代码，选择后，其值为y。而笔者自己写的直接使用了语句obj-y，表示变量值为y（其实就是yes），所以直接就可见了，不依赖于其他的代码。
那么整一个过程就如上三步了，现在执行make menuconfig命令查看是否能看到前面建立的菜单。如下图：
如上两图即为所使用的tristate关键字所表现出的三态结果了，即就是三种状态。可以按照需要进行合适的选择即可。