Windows 和 Linux 是当今两款最主流的服务器操作系统产品，都拥有广泛的用户和信徒。Windows 通过强大的商业运作，驱动了大量优秀人才加盟到它的开发团队中；Linux 通过社区产品的魅力吸引着世界上大量的顶级程序员为它贡献源代码、解答问题。两者在服务器市场上竞争激烈，不分伯仲，但也存在互相扶持的关系。

我觉得，两个操作系统各有千秋。每次学习两个操作系统的技术知识，都让我切实地感受到编程真的是一门艺术，而学习编程就像是在探索艺术。

今天我们继续从一道面试题目“ Linux 内核和 Windows 内核有什么区别？”入手，去了解这两个操作系统内核的设计，帮助你学习操作系统中最核心的一个概念——内核，并希望这些知识可以伴随你日后的每个系统设计。

什么是内核？
说到操作系统，就必须说内核。内核是操作系统中应用连接硬件设备的桥梁。

内核的能力
对于一个现代的操作系统来说，它的内核至少应该提供以下 4 种基本能力：

管理进程、线程（决定哪个进程、线程使用 CPU）；

管理内存（决定内存用来做什么）；

连接硬件设备（为进程、和设备间提供通信能力）；

提供系统调用（接收进程发送来的系统调用）。

操作系统分层
从上面 4 种能力来看操作系统和内核之间的关系，通常可以把操作系统分成 3 层，最底层的硬件设备抽象、中间的内核和最上层的应用。

内核是如何工作的？
为了帮助你理解什么是内核，请你先思考一个问题：进程和内核的关系，是不是像浏览器请求服务端服务？你可以先自己思考，然后在留言区写下你此时此刻对这个问题的认知，等学完“模块三”再反过头来回顾这个知识，相信你定会产生新的理解。

接下来，我们先一起分析一下这个问题。

内核权限非常高，它可以管理进程、可以直接访问所有的内存，因此确实需要和进程之间有一定的隔离。这个隔离用类似请求/响应的模型，非常符合常理。

但不同的是在浏览器、服务端模型中，浏览器和服务端是用不同的机器在执行，因此不需要共享一个 CPU。但是在进程调用内核的过程中，这里是存在资源共享的。

比如，一个机器有 4 个 CPU，不可能让内核用一个 CPU，其他进程用剩下的 CPU。这样太浪费资源了。

再比如，进程向内核请求 100M 的内存，内核把 100M 的数据传回去。 这个模型不可行，因为传输太慢了。

所以，这里多数操作系统的设计都遵循一个原则：进程向内核发起一个请求，然后将 CPU 执行权限让出给内核。内核接手 CPU 执行权限，然后完成请求，再转让出 CPU 执行权限给调用进程。

关于这块知识，我们会在“ 14 |户态和内核态：用户态线程和内核态线程有什么区别？”中详细讨论。

Linux 的设计
Linux 操作系统第一版是1991 年林纳斯托·瓦兹（一个芬兰的小伙子，当时 22 岁）用 C 语音写的。 写完之后他在网络上发布了 Linux 内核的源代码。又经过了 3 年的努力，在 1994 年发布了完整的核心 Version 1.0。

说到 Linux 内核设计，这里有很多有意思的名词。大多数听起来复杂、专业，但是理解起来其实很简单。接下来我们一一讨论。

Multitask and SMP（Symmetric multiprocessing）

MultiTask 指多任务，Linux 是一个多任务的操作系统。多任务就是多个任务可以同时执行，这里的“同时”并不是要求并发，而是在一段时间内可以执行多个任务。当然 Linux 支持并发。

SMP 指对称多处理。其实是说 Linux 下每个处理器的地位是相等的，内存对多个处理器来说是共享的，每个处理器都可以访问完整的内存和硬件资源。 这个特点决定了在 Linux 上不会存在一个特定的处理器处理用户程序或者内核程序，它们可以被分配到任何一个处理器上执行。

ELF（Executable and Linkable Format）

这个名词翻译过来叫作可执行文件链接格式。这是一种从 Unix 继承而来的可执行文件的存储格式。我们可以看到 ELF 中把文件分成了一个个分段（Segment），每个段都有自己的作用。如果想要深入了解这块知识，会涉及部分编译原理的知识，如果你感兴趣可以去网上多查些资料或者去留言区我们一起讨论。

Monolithic Kernel

这个名词翻译过来就是宏内核，宏内核反义词就是 Microkernel ，微内核的意思。Linux 是宏内核架构，这说明 Linux 的内核是一个完整的可执行程序，且内核用最高权限来运行。宏内核的特点就是有很多程序会打包在内核中，比如，文件系统、驱动、内存管理等。当然这并不是说，每次安装驱动都需要重新编译内核，现在 Linux 也可以动态加载内核模块。所以哪些模块在内核层，哪些模块在用户层，这是一种系统层的拆分，并不是很强的物理隔离。

与宏内核对应，接下来说说微内核，内核只保留最基本的能力。比如进程调度、虚拟内存、中断。多数应用，甚至包括驱动程序、文件系统，是在用户空间管理的。

学到这里，你可能会问：在内核层和在用户层有什么区别吗？

感觉分层其实差不多。 我这里说一个很大的区别，比如说驱动程序是需要频繁调用底层能力的，如果在内核中，性能肯定会好很多。对于微内核设计，驱动在内核外，驱动和硬件设备交互就需要频繁做内核态的切换。

当然微内核也有它的好处，比如说微内核体积更小、可移植性更强。不过我认为，随着计算能力、存储技术越来越发达，体积小、安装快已经不能算是一个很大的优势了。现在更重要的是如何有效利用硬件设备的性能。

之所以这么思考，也可能因为我是带着现代的目光回望当时人们对内核的评判，事实上，当时 Linux 团队也因此争论过很长一段时间。 但是我觉得历史往往是螺旋上升的，说不定将来性能发展到了一个新的阶段，像微内核的灵活性、可以提供强大的抽象能力这样的特点，又重新受到人们的重视。

还有一种就是混合类型内核。 混合类型的特点就是架构像微内核，内核中会有一个最小版本的内核，其他功能会在这个能力上搭建。但是实现的时候，是用宏内核的方式实现的，就是内核被做成了一个完整的程序，大部分功能都包含在内核中。就是在宏内核之内有抽象出了一个微内核。

上面我们大体介绍了内核几个重要的特性，有关进程、内存、虚拟化等特性，我们会在后面几个模块中逐步讨论。

Window 设计
接下来我们说说 Windows 的设计，Windows 和 Linux 的设计有很大程度的相似性。Windows也有内核，它的内核是 C/C++ 写的。准确地说，Windows 有两个内核版本。一个是早期的Windows 9x 内核，早期的 Win95, Win98 都是这个内核。我们今天用的 Windows 7, Windows 10 是另一个内核，叫作 Windows NT。NT 指的是 New Technology。接下来我们讨论的都是 NT 版本的内核。

下面我找到一张 Windows 内核架构的图片给你一个直观感受。

Windows 同样支持 Multitask 和 SMP（对称多处理）。Windows 的内核设计属于混合类型。你可以看到内核中有一个 Microkernel 模块。而整个内核实现又像宏内核一样，含有的能力非常多，是一个完整的整体。

Windows 下也有自己的可执行文件格式，这个格式叫作 Portable Executable（PE），也就是可移植执行文件，扩展名通常是.exe、.dll、.sys等。

PE 文件的结构和 ELF 结构有很多相通的地方，我找到了一张图片帮助你更直观地理解。 因为这部分知识涉及编译原理，我这里就不详细介绍了，感兴趣同学可以在留言区和大家一起讨论，或者查阅更多资料。

Windows 还有很多独特的能力，比如 Hyper-V 虚拟化技术，有关虚拟化技术我们将在“模块八：虚拟化和其他”中详细讲解。

总结
这一讲我们学习了内核的基础知识，包括内核的作用、整体架构以及 3 种内核类型（宏内核、微内核和混合类型内核）。内核很小（微内核）方便移植，因为体积小、安装快；内核大（宏内核），方便优化性能，毕竟内核更了解计算机中的资源。我们还学习了操作系统对执行文件的抽象，但是没有很深入讨论，内核部分有很多知识是需要在后面的几个模块中体现的，比如进程、文件、内存相关的能力等。

那么通过这一讲的学习，你现在可以来回答本节关联的面试题目：Linux 内核和 Windows 内核有什么区别？

老规矩，请你先在脑海里构思下给面试官的表述，并把你的思考写在留言区，然后再来看我接下来的分析。

【解析】 Windows 有两个内核，最新的是 NT 内核，目前主流的 Windows 产品都是 NT 内核。NT 内核和 Linux 内核非常相似，没有太大的结构化差异。

从整体设计上来看，Linux 是宏内核，NT 内核属于混合型内核。和微内核不同，宏内核和混合类型内核从实现上来看是一个完整的程序。只不过混合类型内核内部也抽象出了微内核的概念，从内核内部看混合型内核的架构更像微内核。

另外 NT 内核和 Linux 内核还存在着许多其他的差异，比如：

Linux 内核是一个开源的内核；

它们支持的可执行文件格式不同；

它们用到的虚拟化技术不同。

关于这块知识就不展开说了， 我们会在后续的“进程、内存、虚拟化”等模块中仔细讨论。

宏内核和微内核的基本概念

    宏内核：简单来说，就是把很多东西都集成进内核，例如linux内核，除了最基本的进程、线程管理、内存管理外，文件系统，驱动，网络协议等等都在内核里面。将内核从整体上作为一个大过程实现，并同时运行在一个单独的地址空间。所有的内核服务都在一个地址空间运行，相互之间直接调用函数，简单高效。

优点：效率高

缺点：稳定性差、开发过程中的bug经常会导致整个系统挂掉

    微内核：内核中只有最基本的调度、内存管理。驱动、文件系统等都是用户态的守护进程去实现的，微内核中功能被划分成独立的过程，过程间通过IPC进行通信。模块化程度高，一个服务失效不会影响另外一个服务。

优点：超级稳定，驱动等的错误只会导致相应进程死掉，不会导致整个系统都崩溃，做驱动开发时，发现错误，只需要kill掉进程，修正后重启进程就行了，比较方便。

缺点：效率低。典型代表QNX，QNX的文件系统是跑在用户态的进程，称为resmgr的东西，是订阅发布机制，文件系统的错误只会导致这个守护进程挂掉。不过数据吞吐量就比较不乐观了。

Linux是宏内核还是微内核？

    Linux是一个单内核结构，同时又吸收了微内核的优点：模块化设计，支持动态装载内核模块。Linux还避免了微内核设计上的缺陷，让一切都运行在内核态，直接调用函数，无需消息传递。

    Linux大部分都是单内核的。

宏内核、微内核详解

    微内核（Microkernel kernel）――在微内核中，大部分内核都作为单独的进程在特权状态下运行，他们通过消息传递进行通讯。在典型情况下，每个概念模块都有一个进程。因此，假如在设计中有一个系统调用模块，那么就必然有一个相应的进程来接收系统调用，并和能够执行系统调用的其他进程（或模块）通讯以完成所需任务。

    在这些设计中，微内核部分经常只是个消息转发站：当系统调用模块要给文档系统模块发送消息时，消息直接通过内核转发。这种方式有助于实现模块间的隔离。（某些时候，模块也能够直接给其他模块传递消息）在一些微内核的设计中，更多的功能，如I/O等，也都被封装在内核中了。但是最根本的思想还是要保持微内核尽量小，这样只需要把微内核本身进行移植就能够完成将整个内核移植到新的平台上。其他模块都只依赖于微内核或其他模块，并不直接直接依赖硬件。

    微内核设计的一个长处是在不影响系统其他部分的情况下，用更高效的实现代替现有文档系统模块的工作将会更加容易。我们甚至能够在系统运行时将研发出的新系统模块或需要替换现有模块的模块直接而且迅速的加入系统。另外一个长处是无需的模块将不会被加载到内存中，因此微内核就能够更有效的利用内存。

    单内核（Monolithic kernel）――单内核是个很大的进程。他的内部又能够被分为若干模块（或是层次或其他）。但是在运行的时候，他是个单独的二进制大映象。其模块间的通讯是通过直接调用其他模块中的函数实现的，而不是消息传递。

    单内核的支持者声称微内核的消息传递开销引起了效率的损失。微内核的支持者则认为因此而增加的内核设计的灵活性和可维护性能够弥补任何损失。

    这种争论经常会令人想到前几年CPU领域中RISC和CISC的斗争。现代的成功CPU设计中包含了任何这两种技术，就像Linux内核是微内核和单一内核的混合产物相同。Linux内核基本上是单一的，但是他并不是个纯粹的集成内核。前面一章所介绍的内核模块系统将微内核的许多长处引入到Linux的单内核设计中。（顺便提一下，我考虑过一种有趣的情况，就是Linux的内核模块系统能够将系统内核转化成为简单的不传递消息的微内核设计。虽然我并不赞成，但是他仍然是个有趣的想法。）

    为什么Linux必然是单内核的呢？一个方面是历史的原因：在Linus的观点看来，通过把内核以单一的方式进行组织并在最初始的空间中运行是相当容易的事情。这种决策避免了有关消息传递体系结构、计算模块装载方式等方面的相关工作。

    另外一个原因是充足的研发时间的结果。Linux既没有研发时间的限制，也没有深受市场压力的发行进度。任何的限制只有并但是分的对内核的修改和扩充。内核的单一设计在内部实现了充分的模块化，在这种条件下的修改或增加都并不怎么困难。而且问题还在于没有必要为了追求尚未证实的可维护性的微小增长而重写Linux的内核。（Linus曾多次特别强调了如下的观点：为了这点利益而损耗速度是不值得的）后面章节中的部分内容将周详的重新考虑充足研发时间的效果。

    假如Linux是纯微内核设计，那么向其他体系结构上的移植将会比较容易。实际上，有一些微内核，如Mach微内核，就已成功的证实了这种可移植性的长处。实际的情况是，Linux内核的移植虽然不是很简单，但也绝不是不可能的：大约的数字是，向一个全新的体系结构上的典型的移植工作需要 30,000到 60,000行代码，再加上不到20,000行的驱动程式代码。（并不是任何的移植都需要新的驱动程式代码。）粗略的计算一下，我估计一个典型的移植平均需要50,000行代码。这对于一个程式员或最多一个程式小组来说是力所能及的，能够在一年之内完成。虽然这比微内核的移植需要更多的代码，但是 Linux的支持者将会提出，这样的Linux内核移植版本比微内核更能够有效的利用底层硬件，因而移植过程中的额外工作是能够从系统性能的提高上得到补偿的。

    这种特别设计的权衡也不是很轻松就能够达到的，单内核的实现策略公然违背了传统的看法，后者认为微内核是未来发展的趋势。但是由于单一模式（大部分情况下）在Linux中运行状态良好，而且内核移植相对来说比较困难，但没有明显地阻碍程式员团体的工作，他们已热情高涨地把内核成功的移植到了现存的大部分实际系统中，更不用说类似掌上电脑的一些看起来很不实际的目标了。只要Linux的众多特点仍然值得移植，新的移植版本就会不断涌现。

    所有的Unix内核都同宗同源，并且提供相同的API，现代的Unix内核存在许多设计上的相似之处。Unix内核几乎毫无例外的都是一个不可分割的静态可执行块（文件）。也就是说，它们必须以完整、单独的可执行块的形式在一个单独的地址空间中运行。

    Unix内核几乎都需要硬件系统提供页机制以管理内存。这种页机制可以加强内存空间的保护，并保证每个进程都可以运行于不同的虚地址空间上。

单内核与微内核设计比较

    操作系统内核可以分为两大设计阵营：单内核和微内核（第三阵营外内核，主要用在科研系统中，但也逐渐在现实世界中壮大起来）。

    单内核是两大阵营中一种较为简单的设计，在1980年之前，所有的内核都设计成单内核。所谓单内核就是把它从整体上作为一个单独的大过程来实现，并同时运行在一个单独的地址空间。因此，这样的内核通常以单个静态二进制文件的形式存放于磁盘。所有内核服务都在这样的一个大内核空间中运行。内核之间的通信是微不足道的，因为大家都运行在内核态，并身处同一地址空间：内核可以直接调用函数，这与用户空间没有什么区别。这种模式的支持者认为单模块具有简单和高性能的特点。大多数Unix系统都设计为单模块。

    另一方面，微内核并不作为一个单独的大过程来实现。相反，微内核的功能被划分为独立的过程，每个过程叫做一个服务器。理想情况下，只有强烈请求特权服务的服务器才运行在特权模式下，其他服务器都运行在用户空间。不过，所有的服务器都保持独立并运行在各自的地址空间。因此，就不可能像单模块内核那样直接调用函数，而是通过消息传递处理微内核通信：系统采用了进程间通信(IPC)机制，因此，各种服务器之间通过IPC机制互通消息，互换“服务”。服务器的各自独立有效地避免了一个服务器的失效祸及另一个。

    同样，模块化的系统允许一个服务器为了另一个服务器而换出。因为IPC机制的开销比函数调用多，又因为会涉及内核空间到用户空间的上下文切换，因此，消息传递需要一定的周期，而单内核中简单的函数调用没有这些开销。基于此，付之于实际的微内核系统让大部分或全部服务器位于内核，这样，就可以直接调用函数，消除频繁的上下文切换。Windows NT内核和Mach（Mac OS X的组成部分）是微内核的典型实例。不管是Windows NT还是Mac OS X，都在其新近版本中不让任何微内核服务器运行在用户空间，这违背了微内核设计的初衷。

    Linux是一个单内核，也就是说，Linux内核运行在单独的内核地址空间。不过，Linux汲取了微内核的精华：其引以为豪的是模块化设计、抢占式内核、支持内核线程以及动态装载内核模块的能力。不仅如此，Linux还避其微内核设计上性能损失的缺陷，让所有事情都运行在内核态，直接调用函数，无需消息传递。至今，Linux是模块化的、多线程的以及内核本身可调度的操作系统。实用主义再次占了上风。

    当Linus和其他内核开发者设计Linux内核时，他们并没有完全彻底地与Unix诀别。他们充分地认识到，不能忽视Unix的底蕴（特别是 Unix的 API）。而由于Linux并没有基于某种特定的Unix，Linus和他的伙伴们对每个特定的问题都可以选择已知最理想的解决方案—在有些时候，当然也可以创造一些新的方案。以下是对Linux内核与Unix各种变体的内核特点所作的分析比较：

• Linux支持动态加载内核模块。尽管Linux内核也是单内核，可是允许在需要的时候动态地卸除和加载部分内核代码。

• Linux支持对称多处理（SMP）机制，尽管许多Unix的变体也支持SMP，但传统的Unix并不支持这种机制。

• Linux内核可以抢占（preemptive）。与传统的Unix不同，Linux内核具有允许在内核运行的任务优先执行的能力。在其他各种Unix产品中，只有Solaris和IRIX支持抢占，但是大多数传统的Unix内核不支持抢占。

• Linux对线程支持的实现比较有意思：内核并不区分线程和其他的一般进程。对于内核来说，所有的进程都一样—只不过其中的一些共享资源而已。

• Linux提供具有设备类的面向对象的设备模型、热插拔事件，以及用户空间的设备文件系统（sysfs）。

• Linux忽略了一些被认为是设计得很拙劣的Unix特性，像STREAMS，它还忽略了那些实际上已经根本不会使用的过时标准。

• Linux体现了自由这个词的精髓。现有的Linux特性集就是Linux公开开发模型自由发展的结果。如果一个特性没有任何价值或者创意很差，没有任何人会被迫去实现它。相反的，在Linux的发展过程中已经形成了一种值得称赞的务实态度：任何改变都要针对现实中确实存在的问题，经过完善的设计并有正确简洁的实现。于是，许多其他现代Unix系统包含的特性，如内核换页机制，都被毫不迟疑的引入进来。

不管Linux和Unix有多大的不同，它身上都深深地打上了Unix烙印

首先加压开发过程自带的内核包，然后减压并打补丁，将厂家给的配置文件config_ok复制成为.config，最后执行make命令完成内核编译。减压和打补丁功能不多过多的描述，对于系统具体支持的模块进行配置。配置方式除了使用自己的方式，还可以通过make menuconfig看有配置界面出来，进行相应的配置。最后进行编译。

tar jxf linux-2.6.22.6.tar.bz2
patch -p1 < ../package/linux-2.6.22.6_jz2440.patch
cp config_ok .config
make uImage

kernel打补丁,编译流程
内核源码包: linux-2.6.22.6.tar.bz2
补丁文件: linux-2.6.22.6_jz2440_v2v3.patch

1. 解压
    tar xjf linux-2.6.22.6.tar.bz2
2. 打补丁
    cd linux-2.6.22.6                                // 先进入源码顶层目录
    patch -p1 < ../linux-2.6.22.6_jz2440_v2v3.patch    // -p1 表示忽略补丁文件中的第一层目录
    
3. 配置, 配置的结果是为了生成.config
    3.1 可以直接执行make menuconfig   从头到尾每一项都去配置一下
    3.2 可以使用默认配置， 在默认配置上修改    
        find ./ -name "*defconfig" 命令可以找到默认配置文件,
        arm架构默认配置文件所在目录linux-2.6.22.6/arch/arm/configs
        在linux-2.6.22.6/arch/arm/configs目录下找到合适的默认配置文件, 比如s3c2410_defconfig
        回到顶层目录执行
            make s3c2410_defconfig   // 所有配置信息保存到.config文件里面
        然后执行
            make    menuconfig         // 读取.config文件，修改菜单配置项

   3.3  使用厂家提供的配置文件
        找到厂家的配置文件，比如 config.ok
        把config_ok复制为.config
            cp  cofig.ok  .config
        然后执行
            make   menuconfig         // 读取.config文件，修改菜单配置项

                  
4、编译
    make   uImage      // uImage 是  头部  +  真正内核  的镜像文件                  
                  
                  
配置的结果就是生成了一个.config文件:
下面分析.config文件
里面是一些配置项, 配置项由以下几种值
                  =y 表示对这一选项的支持会编进内核里面去
                  =m 表示对这一选项的支持会编译成模块, 模块可以动态加载
                  is no set 表示未设置改选项
                  
以CONFIG_DM9000=y为例:
搜索该选项包含的文件: grep "CONFIG_DM9000" * -nwR
book@www.100ask.org:/work/system/linux-2.6.22.6$ grep "CONFIG_DM9000" * -nwR
...
arch/arm/configs/s3c2410_defconfig:588:CONFIG_DM9000=y
...
arch/arm/plat-s3c24xx/common-smdk.c:46:#if defined(CONFIG_DM9000) || defined(CONFIG_DM9000_MODULE)
arch/arm/plat-s3c24xx/common-smdk.c:162:#if defined(CONFIG_DM9000) || defined(CONFIG_DM9000_MODULE)
arch/arm/plat-s3c24xx/common-smdk.c:200:#endif /* CONFIG_DM9000 */
arch/arm/plat-s3c24xx/common-smdk.c:250:#if defined(CONFIG_DM9000) || defined(CONFIG_DM9000_MODULE)
...
drivers/net/Makefile:197:obj-$(CONFIG_DM9000) += dm9dev9000c.o
drivers/net/Makefile:198:#obj-$(CONFIG_DM9000) += dm9000.o
drivers/net/Makefile:199:#obj-$(CONFIG_DM9000) += dm9ks.o
include/config/auto.conf:144:CONFIG_DM9000=y
include/linux/autoconf.h:145:#define CONFIG_DM9000 1

可以发现有以下几种文件用到了CONFIG_DM9000配置项:
1. C源码文件 用到CONFIG_DM9000宏, 在include/linux/autoconf.h中定义
2. 子目录drivers/net/Makefile
3. include/config/auto.conf
4. include/linux/autoconf.h  定义CONFIG_DM9000宏

include/linux/autoconf.h从名字可以看出autoconf.h是自动生成的,
autoconf.h的内容来源于.config,
当make uImage时候, make机制会自动的根据.config生成autoconf.h

下面分析include/linux/autoconf.h:
可以看到里面定义了一些宏, 这些宏几乎都被定义为1
.config中的配置项不管是=y或=m着这里都会被定义为1, 其他配置项定义了数据的都会照搬过来
#define CONFIG_DM9000 1

而.config配置项=m或=y是在子目录Makefile中体现
下面分析子目录Makefile:
obj-y += xxx.o // 表示xxx.o文件最终会被编译进内核里面
obj-m += aaa.o // 表示aaa.o文件最终会被编译成一个可加载的.ko模块里面

在子目录drivers/net/Makefile中
就是用到了.config中的CONFIG_DM9000=y

obj-$(CONFIG_DM9000) += dm9000c.o
=>
obj-y += dm9000c.o // 这样就会把dm9000c.o编译进内核

综上:
1. include/linux/autoconf.h所定义的宏来源于.config
2. 子目录的Makefile定义的obj-$(CONFIG_xx)是根据.config中的CONFIG_xxx=y或CONFIG_xxx=m决定的

子目录下的Makefile用到的配置项哪里来的???
来源于include/config/auto.conf, 而include/config/auto.conf也是来源于.config
include/config/auto.conf是根据.config自动生成的, 会被顶层Makefile包含用来给子目录Makefile使用

make uImage过程总结:
1、.config被用来自动创建include/linux/autoconf.h文件，给源代码使用
2、.config被用来自动创建include/config/auto.conf文件，被顶层Makefile来包含，给子目录下Makefile使用

下面从顶层Makefile分析.
 

3. Makefile分析

3.1. make help

直接打印方式给定了当前Makefile进行编译的方式和方法以及对应的编译结果放置在具体的位置。

编译过程中

MAKEFLAGS += -rR --no-print-directory 宏禁止在编译过程中打印目录的跳转动作，只显示编译目录文件所在的目录位置。

编译过程每个目录文件内部包含了自己的Makefile文件，也就是sub-makefile，只需要针对性修改相关的文件就可以实现本目录的编译。如果当前文件以来其他目录，在其他目录中定义的Makefile文件可能被应用。但是这种情况比较少发生。

V参数解析，如果命令行制定了V参数，获取赋值给KBUILD_VERBOSE，如果没有则默认参数为0，也就是默认不会有任何编译过程打印。

C参数戈丁当前代码检查作为C编译器的内容，1表示只检查从编译的文件。

M参数指定外部模块编译目录

O参数指定编译输出目录

获取代码目录和编译目录

SUBARCH指定用户当前执行的环境芯片架构类型

之后指定编译目的主机的ARCH架构，可以通过make来指定这个参数，未指定情况下默认是宿主机的编译内容

加载内核.config配置文件

指定内核使用shell，也同时指定内核编译工具链，编译模块等基本信息并export出来

Beautify output根据之前指定是否安静编译确定最终的编译输出内容

include $(srctree)/scripts/Kbuild.include文件制定了编译过程其他命令表示形式和安静编译的一些基本行为

Read KERNELRELEASE from include/config/kernel.release 获取内核基本发布和版本信息内容

将scripts中basic的内容包含进来进行编译，这个目录具体应该是文档相关的目录生成函数