Linux内核剖析（五）Linux内核的构建过程

参考
一次实验引发的故事 – kernel build system探索—vmlinux是如何炼成的– kernel makefile

深度探索Linux操作系统：系统构建和原理解析.pdf

问题

---

在前面的博文中，我们先是为自己的Ubuntu安装了一套内核源码树，然后为了方便进行嵌入式交叉编译，我们又为arm板子构建了一套源码树。
那么现在我们已经知道如何自己的电脑上去构建、安装一个定制化的Linux内核，但是我们还是要在唠叨一些。
当你在内核源码路径里敲下make时究竟发生什么

当我们刚刚开始接触内核代码时，毫无头绪，这时候Makefile是往往是我们打开的第一个文件，这个makefile是Linux内核代码的根makefile，内核构建就始于此处。是的，它的内容很多，但是如果你已经读过内核源代码，你就会发现每个包含代码的目录都有一个自己的Makefile。当然了，我们不会去描述每个代码文件是怎么编译链接的，所以我们将只会挑选一些通用的例子来说明问题。而你不会在这里找到构建内核的文档、如何整洁内核代码、tags的生成和交叉编译相关的说明，等等。

我们仅仅将从make开始，使用标准的内核配置文件，一直到生成了内核镜像bzImage或者zImage结束。
当然在着之前我们需要了解，我们make究竟是要构建一个什么样的目标，我想这个

构建的目标vmlinux,vmlinuz,bzImage,zImage

---

对于Linux内核，编译可以生成不同格式的映像文件，例如：

make zImag
make uImage

zImage是ARM Linux常用的一种压缩映像文件，uImage是U-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的“头”，说明这个映像文件的类型、加载位置、生成时间、大小等信息。换句话说，如果直接从uImage的0x40位置开始执行，zImage和uImage没有任何区别。另外，Linux2.4内核不支持uImage，Linux2.6内核加入了很多对嵌入式系统的支持，但是uImage的生成也需要设置。

几种linux内核文件的区别：

1、vmlinux 编译出来的最原始的内核文件，未压缩。
2、zImage 是vmlinux经过gzip压缩后的文件。适用于小内核
3、bzImage bz表示“big
zImage”，不是用bzip2压缩的。两者的不同之处在于，zImage解压缩内核到低端内存(第一个640K)，bzImage解压缩内核到高端内存(1M以上)。如果内核比较小，那么采用zImage或bzImage都行，如果比较大应该用bzImage。适用于大内核

4、uImage U-boot专用的映像文件，它是在zImage之前加上一个长度为0x40的tag。
5、vmlinuz 是bzImage/zImage文件的拷贝或指向bzImage/zImage的链接。
6、initrd 是“initial ramdisk”的简写。一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。

vmlinux

---

vmlinux是未压缩的内核，是make工作编译出的原始内核，vmlinuz是vmlinux的压缩文件。

vmlinux 是ELF文件，即编译出来的最原始的文件。

zImage, bzImage和vmlinuz

---

vmlinuz是可引导的、压缩的内核。“vm”代表“Virtual
Memory”。Linux
支持虚拟内存，不像老的操作系统比如DOS有640KB内存的限制。Linux能够使用硬盘空间作为虚拟内存，因此得名“vm”。vmlinuz是可执行的Linux内核，它位于/boot/vmlinuz，它一般是一个软链接,是bzImage/zImage文件的拷贝或指向bzImage/zImage的链接。

vmlinuz的建立有两种方式。

一是编译内核时通过“make zImage”创建，然后通过：“cp /usr/src/linux-2.4/arch/i386/linux/boot/zImage /boot/vmlinuz”产生。zImage适用于小内核的情况，它的存在是为了向后的兼容性。

二是内核编译时通过命令make bzImage创建，然后通过：“cp
/usr/src/linux-2.4/arch/i386/linux/boot/bzImage
/boot/vmlinuz”产生。bzImage是压缩的内核映像，需要注意，bzImage不是用bzip2压缩的，bzImage中的bz容易引起误解，bz表示“big
zImage”。 bzImage中的b是“big”意思。

zImage(vmlinuz)和bzImage(vmlinuz)都是用gzip压缩的。它们不仅是一个压缩文件，而且在这两个文件的开头部分内嵌有gzip解压缩代码。所以你不能用gunzip 或 gzip –dc解包vmlinuz。

内核文件中包含一个微型的gzip用于解压缩内核并引导它。两者的不同之处在于，老的zImage解压缩内核到低端内存(第一个640K)，bzImage解压缩内核到高端内存(1M以上)。如果内核比较小，那么可以采用zImage
或bzImage之一，两种方式引导的系统运行时是相同的。大的内核采用bzImage，不能采用zImage。

但是注意通常情况下是不能用vmlinuz解压缩得到vmlinux的

initrd-x.x.x.img

---

initrd是“initial ramdisk”的简写。initrd一般被用来临时的引导硬件到实际内核vmlinuz能够接管并继续引导的状态。

initrd
映象文件是使用mkinitrd创建的。mkinitrd实用程序能够创建initrd映象文件。这个命令是RedHat专有的。其它Linux发行版或许有相应的命令。这是个很方便的实用程序。具体情况请看帮助:man
mkinitrd下面的命令创建initrd映象文件。

最后生成的内核镜象有两种 zImage 以及 uImage 。其中 zImage
下载到目标板中后，可以直接用 uboot 的命令 go 来进行直接跳转。这时候内核直接解压启动。但是无法挂载文件系统，因为 go
命令没有将内核需要的相关的启动参数传递给内核。传递启动参数我们必须使用命令 bootm 来进行跳转。 Bootm 命令跳转只处理 uImage
的镜象。

uboot 源代码的 tools/ 目录下有 mkimage 工具，这个工具可以用来制作不压缩或者压缩的多种可启动映象文件。

mkimage 在制作映象文件的时候，是在原来的可执行映象文件的前面加上一个 0x40
字节的头，记录参数所指定的信息，这样 uboot 才能识别这个映象是针对哪个 CPU 体系结构的，哪个 OS
的，哪种类型，加载内存中的哪个位置， 入口点在内存的那个位置以及映象名是什么

uImage文件

---

　　vmlinux是内核文件，zImage是一般情况下默认的压缩内核映像文件，压缩vmlinux，加上一段解压启动代码得到。而uImage
则是使用工具mkimage对普通的压缩内核映像文件（zImage）加工而得。它是uboot专用的映像文件，它是在zImage之前加上一个长度为
64字节的“头”，说明这个内核的版本、加载位置、生成时间、大小等信息；其0x40之后与zImage没区别。
其实就是一个自动跟手动的区别,有了uImage头部的描述,u-boot就知道对应Image的信息,如果没有头部则需要自己手动去搞那些参数。
如何生成
uImage文件？首先在uboot的/tools目录下寻找mkimage文件，把其copy到系统/usr/local/bin目录下，这样就完成制
作工具。然后在内核目录下运行make uImage，如果成功，便可以在arch/arm/boot/目录下发现uImage文件，其大小比
zImage多64个字节。
此外，平时调试用uImage，不用去管调整了哪些东西；zImage则是一切OK后直接烧0X0。开机就运行

编译内核前的准备

---

在开始编译前要进行很多准备工作。最主要的就是找到并配置好配置文件，make命令要使用到的参数都需要从这些配置文件获取。现在就让我们深入内核的根makefile吧

内核版本设定

---

内核的根Makefile负责构建两个主要的文件：vmlinux（内核镜像可执行文件）和模块文件moudles。
我们先看看内核的Makefile开始的几行head -n 6 Makefile

VERSION = 4
PATCHLEVEL = 2
SUBLEVEL = 3
EXTRAVERSION =
NAME = Hurr durr I'ma sheep

Makefile在开始的时候定义了几个变量，这些变量决定了当前内核的版本，并且被使用在很多不同的地方，比如同一个Makefile中的KERNELVERSION

关于版本号

Linux内核有三个不同的命名方案。

参见 https://zh.wikipedia.org/wiki/Linux%E5%86%85%E6%A0%B8

早期版本

　　第一种方式用于1.0版本之前（包括1.0）。第一个版本的内核是0.01。其次是0.02,0.03,0.10,0.11,0.12（第一GPL版本),0.95,0.96,0.97,0.98,0.99及1.0。从0.95版有许多的补丁发布于主要版本版本之间。

旧计划
　　第二种方式用于1.0之后到2.6，版本的格式为A.B.C，其中A,B,C代表：

　　A大幅度转变的内核。这是很少发生变化，只有当发生重大变化的代码和核心发生才会发生。在历史上曾改变两次的内核：1994年的1.0及1996年的2.0。

　　B是指一些重大修改的内核。内核使用了传统的奇数次要版本号码的软件号码系统（用偶数的次要版本号码来表示稳定版本）。

　　C是指轻微修订的内核。这个数字当有安全补丁,bug修复，新的功能或驱动程序，内核便会有变化。
　　这样稳定版本来源于上一个测试版升级版本号，而一个稳定版本发展到完全成熟后就不再发展。

　　自2.6.0（2003年12月）发布后，人们认识到，更短的发布周期将是有益的。自那时起，版本的格式为A.B.C.D，其中A,B,C,D代表：

　　A和B是无关紧要的
　　C是内核的版本

新计划
　　自3.0（2011年7月）发布后，版本的格式为3.A.B，其中A,B代表：

　　A是内核的版本
　　B是安全补丁

　　使用一种“time-based”的方式。3.0版本之前，是一种“A.B.C.D”的格式。七年里，前两个数字A.B即“2.6”保持不变，C随着新版本的发布而增加,D代表一些bug修复，安全更新，添加新特性和驱动的次数。
　　3.0版本之后是“A.B.C”格式，B随着新版本的发布而增加, C代表一些bug修复，安全更新，新特性和驱动的次数。第三种方式中不再使用偶数代表稳定版，奇数代表开发版这样的命名方式。举个例子：3.7.0代表的不是开发版，而是稳定版！

　　而4.0（2015年4月）发布后，则延续3.A.B的命名格式，只是将主版号变更为4。

make参数传递

---

　　接下来我们会看到很多ifeq条件判断语句，它们负责检查传递给make的参数。内核的Makefile提供了一个特殊的编译选项makehelp，这个选项可以生成所有的可用目标和一些能传给make的有效的命令行参数。
　　举个例子，首先出现的就是-V ，那么make V=1会在构建过程中输出详细的编译信息，第一个ifeq就是检查传递给make的V=n选项。

参数-v在控制构建过程中输出编译信息

使用cat -n Makefile | head -n 83 | tail -n +23 查看

# Avoid interference with shell env settings
unexport GREP_OPTIONS

# We are using a recursive build, so we need to do a little thinking
# to get the ordering right.
#
# Most importantly: sub-Makefiles should only ever modify files in
# their own directory. If in some directory we have a dependency on
# a file in another dir (which doesn't happen often, but it's often
# unavoidable when linking the built-in.o targets which finally
# turn into vmlinux), we will call a sub make in that other dir, and
# after that we are sure that everything which is in that other dir
# is now up to date.
#
# The only cases where we need to modify files which have global
# effects are thus separated out and done before the recursive
# descending is started. They are now explicitly listed as the
# prepare rule.

# Beautify output
# ---------------------------------------------------------------------------
#
# Normally, we echo the whole command before executing it. By making
# that echo $($(quiet)$(cmd)), we now have the possibility to set
# $(quiet) to choose other forms of output instead, e.g.
#
#         quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
#         cmd_cc_o_c       = $(CC) $(c_flags) -c -o $@ $<
#
# If $(quiet) is empty, the whole command will be printed.
# If it is set to "quiet_", only the short version will be printed.
# If it is set to "silent_", nothing will be printed at all, since
# the variable $(silent_cmd_cc_o_c) doesn't exist.
#
# A simple variant is to prefix commands with $(Q) - that's useful
# for commands that shall be hidden in non-verbose mode.
#
#   $(Q)ln $@ :<
#
# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
# If KBUILD_VERBOSE equals 1 then the above command is displayed.
#
# To put more focus on warnings, be less verbose as default
# Use 'make V=1' to see the full commands

ifeq ("$(origin V)", "command line")
  KBUILD_VERBOSE = $(V)
endif
ifndef KBUILD_VERBOSE
  KBUILD_VERBOSE = 0
endif

ifeq ($(KBUILD_VERBOSE),1)
  quiet =
  Q =
else
  quiet=quiet_
  Q = @
endif

　　如果V=n这个选项传给了make，系统就会给变量KBUILD_VERBOSE选项附上V的值，否则的话KBUILD_VERBOSE就会为0。然后系统会检查KBUILD_VERBOSE的值，以此来决定quiet和Q的值。符号@控制命令的输出，如果它被放在一个命令之前，这条命令的输出将会是CCscripts/mod/empty.o，而不是Compiling….scripts/mod/empty.o（LCTT译注：CC在makefile中一般都是编译命令）。在这段最后，系统导出了所有的变量。

参数-s

然后是-s 的控制

# If the user is running make -s (silent mode), suppress echoing of
# commands

ifneq ($(filter 4.%,$(MAKE_VERSION)),)   # make-4
ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
  quiet=silent_
endif
else                    # make-3.8x
ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
  quiet=silent_
endif
endif

export quiet Q KBUILD_VERBOSE

参数-O

---

　　下一个ifeq语句检查的是传递给make的选项O=/dir，这个选项允许在指定的目录dir输出所有的结果文件
使用 cat -n Makefile | head -n 153 | tail -n +127 查看

# Cancel implicit rules on top Makefile
$(CURDIR)/Makefile Makefile: ;

ifneq ($(KBUILD_OUTPUT),)
# Invoke a second make in the output directory, passing relevant variables
# check that the output directory actually exists
saved-output := $(KBUILD_OUTPUT)
KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \
                                && /bin/pwd)
$(if $(KBUILD_OUTPUT),, \
     $(error failed to create output directory "$(saved-output)"))

PHONY += $(MAKECMDGOALS) sub-make

$(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make
    @:

sub-make: FORCE
    $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
    -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))

# Leave processing to above invocation of make
skip-makefile := 1
endif # ifneq ($(KBUILD_OUTPUT),)
endif # ifeq ($(KBUILD_SRC),)

　　
　　系统会检查变量KBUILD_SRC，它代表内核代码的顶层目录，如果它是空的（第一次执行makefile时总是空的），我们会设置变量KBUILD_OUTPUT为传递给选项O的值（如果这个选项被传进来了）。下一步会检查变量KBUILD_OUTPUT，如果已经设置好，那么接下来会做以下几件事：

　　将变量KBUILD_OUTPUT的值保存到临时变量saved-output；
　　尝试创建给定的输出目录；
　　检查创建的输出目录，如果失败了就打印错误；
　　如果成功创建了输出目录，那么就在新目录重新执行make命令（参见选项-C）。
　　

选项C

下一个ifeq语句会检查传递给make的选项C
使用 cat -n Makefile | head -n 178 | tail -n +153 查看

# We process the rest of the Makefile if this is the final invocation of make
ifeq ($(skip-makefile),)

# Do not print "Entering directory ...",
# but we want to display it when entering to the output directory
# so that IDEs/editors are able to understand relative filenames.
MAKEFLAGS += --no-print-directory

# Call a source code checker (by default, "sparse") as part of the
# C compilation.
#
# Use 'make C=1' to enable checking of only re-compiled files.
# Use 'make C=2' to enable checking of *all* source files, regardless
# of whether they are re-compiled or not.
#
# See the file "Documentation/sparse.txt" for more details, including
# where to get the "sparse" utility.

ifeq ("$(origin C)", "command line")
  KBUILD_CHECKSRC = $(C)
endif
ifndef KBUILD_CHECKSRC
  KBUILD_CHECKSRC = 0
endif

选项C会告诉makefile需要使用环境变量$CHECK提供的工具来检查全部c代码，默认情况下会使用sparse。

我们可以看到之前先检查了skip-makefile ，这个变量在选项O的时候被定义为1

选项M

选项M会用来编译外部模块
使用cat -n Makefile | head -n 198 | tail -n +178 查看

# Use make M=dir to specify directory of external module to build
# Old syntax make ... SUBDIRS=$PWD is still supported
# Setting the environment variable KBUILD_EXTMOD take precedence
ifdef SUBDIRS
  KBUILD_EXTMOD ?= $(SUBDIRS)
endif

ifeq ("$(origin M)", "command line")
  KBUILD_EXTMOD := $(M)
endif

# If building an external module we do not care about the all: rule
# but instead _all depend on modules
PHONY += all
ifeq ($(KBUILD_EXTMOD),)
    _all: all
else
    _all: modules
endif

设置objtree

紧接着系统检查了变量KBUILD_SRC ，如果KBUILD_SRC 没有被设置，系统会设置变量srctree为当前目录./, 使用cat -n Makefile | head -n 215 | tail -n +198 进行查看

ifeq ($(KBUILD_SRC),)
        # building in the source tree
        srctree := .
else
        ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR)))
                # building in a subdirectory of the source tree
                srctree := ..
        else
                srctree := $(KBUILD_SRC)
        endif
endif
objtree     := .
src     := $(srctree)
obj     := $(objtree)

VPATH       := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD))

export srctree objtree VPATH

这将会告诉Makefile内核的源码树就在执行make命令的目录，然后要设置objtree和其他变量为这个目录，并且将这些变量导出。

SUBARCH获取系统架构

接着就是要获取SUBARCH的值，这个变量代表了当前的系统架构（LCTT译注：一般都指CPU架构）：
使用cat Makefile | head -n 230 | tail -n +217查看

# SUBARCH tells the usermode build what the underlying arch is.  That is set
# first, and if a usermode build is happening, the "ARCH=um" on the command
# line overrides the setting of ARCH below.  If a native build is happening,
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.

SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
                  -e s/sun4u/sparc64/ \
                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                  -e s/s390x/s390/ -e s/parisc64/parisc/ \
                  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
                  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )

它其实就是执行了如下的命令

uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ -e s/sun4u/sparc64/  -e s/arm.*/arm/ -e s/sa110/arm/ -e s/s390x/s390/ -e s/parisc64/parisc/  -e s/ppc.*/powerpc/ -e s/mips.*/mips/  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ 

我的机子是Ubuntu-Gnome14.04 LTS x86的（即x86架构）运行一下
得到如下信息

如你所见，系统执行uname得到机器、操作系统和架构的信息。因为我们得到的是uname的输出，所以我们需要做一些处理再赋给变量SUBARCH。

依据SUBARCH设置SRCARCH和hfr-arch

获得SUBARCH之后就要设置SRCARCH和hfr-arch

SRCARCH提供了硬件架构相关代码的目录
hfr-arch提供了相关头文件的目录

ARCH        ?= $(SUBARCH)
CROSS_COMPILE   ?= $(CONFIG_CROSS_COMPILE:"%"=%)

# Architecture as present in compile.h
UTS_MACHINE     := $(ARCH)
SRCARCH     := $(ARCH)

# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
        SRCARCH := x86
endif
ifeq ($(ARCH),x86_64)
        SRCARCH := x86
endif

# Additional ARCH settings for sparc
ifeq ($(ARCH),sparc32)
       SRCARCH := sparc
endif
ifeq ($(ARCH),sparc64)
       SRCARCH := sparc
endif

# Additional ARCH settings for sh
ifeq ($(ARCH),sh64)
       SRCARCH := sh
endif

# Additional ARCH settings for tile
ifeq ($(ARCH),tilepro)
       SRCARCH := tile
endif
ifeq ($(ARCH),tilegx)
       SRCARCH := tile
endif

# Where to locate arch specific headers
hdr-arch  := $(SRCARCH)

注意：ARCH是SUBARCH的别名。

设置KCONFIG_CONFIG

如果没有设置过代表内核配置文件路径的变量KCONFIG_CONFIG，下一步系统会设置它，默认情况下就是.config，这个文件是不是很熟悉,它就是我们make menuconfig后的那个.config配置文件，里面写入我们内核编译的所有信息
使用cat -n Makefile | head -n 292 | tail -n +289 查看

KCONFIG_CONFIG  ?= .config
export KCONFIG_CONFIG

CONFIG_SHELL编译内核过程中要用到的shell

使用cat -n Makefile | head -n 297 | tail -n +292 查看

# SHELL used by kbuild
CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
      else if [ -x /bin/bash ]; then echo /bin/bash; \
      else echo sh; fi ; fi)

编译器以及编译选项

接下来就要设置一组和编译内核的编译器相关的变量。我们会设置主机的C和C++的编译器及相关配置项
使用cat -n Makefile | head -n 307 | tail -n +297 查看

HOSTCC       = gcc
HOSTCXX      = g++
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
HOSTCXXFLAGS = -O2

ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter \
        -Wno-missing-field-initializers -fno-delete-null-pointer-checks
endif

我们可以看到Makefile在这里开始适配代表C/C++编译器的变量CC和CXX
那为什么还要HOST*这些变量呢？这是因为CC是编译内核过程中要使用的目标架构的编译器，但是HOSTCC是要被用来编译一组host程序的（下面我们就会看到）。

KBUILD_编译的目标

然后我们就看到变量KBUILD_MODULES和KBUILD_BUILTIN的定义，这两个变量决定了我们要编译什么东西（内核、模块或者两者都有）：
使用cat -n Makefile | head -n 337 | tail -n +307 查看

# Decide whether to build built-in, modular, or both.
# Normally, just do built-in.

KBUILD_MODULES :=
KBUILD_BUILTIN := 1

# If we have only "make modules", don't compile built-in objects.
# When we're building modules with modversions, we need to consider
# the built-in objects during the descend as well, in order to
# make sure the checksums are up to date before we record them.

ifeq ($(MAKECMDGOALS),modules)
  KBUILD_BUILTIN := $(if $(CONFIG_MODVERSIONS),1)
endif

# If we have "make <whatever> modules", compile modules
# in addition to whatever we do anyway.
# Just "make" or "make all" shall build modules as well

ifneq ($(filter all _all modules,$(MAKECMDGOALS)),)
  KBUILD_MODULES := 1
endif

ifeq ($(MAKECMDGOALS),)
  KBUILD_MODULES := 1
endif

export KBUILD_MODULES KBUILD_BUILTIN
export KBUILD_CHECKSRC KBUILD_SRC KBUILD_EXTMOD

在这我们可以看到这些变量的定义，并且，如果们仅仅传递了modules给make，变量KBUILD_BUILTIN会依赖于内核配置选项CONFIG_MODVERSIONS。

Kbuild

接着下一步操作是引入下面的文件：
使用查看 cat Makefile | head -n 341 | tail -n +337

# We need some generic definitions (do not try to remake the file).
scripts/Kbuild.include: ;
include scripts/Kbuild.include

文件Kbuild或者又叫做KernelBuildSystem是一个用来管理构建内核及其模块的特殊框架。kbuild文件的语法与makefile一样。文件scripts/Kbuild.include为kbuild系统提供了一些常规的定义。因为我们包含了这个kbuild文件，我们可以看到和不同工具关联的这些变量的定义，这些工具会在内核和模块编译过程中被使用（比如链接器、编译器、来自binutils的二进制工具包，等等）：

# Make variables (CC, etc...)
AS      = $(CROSS_COMPILE)as
LD      = $(CROSS_COMPILE)ld
CC      = $(CROSS_COMPILE)gcc
CPP     = $(CC) -E
AR      = $(CROSS_COMPILE)ar
NM      = $(CROSS_COMPILE)nm
STRIP       = $(CROSS_COMPILE)strip
OBJCOPY     = $(CROSS_COMPILE)objcopy
OBJDUMP     = $(CROSS_COMPILE)objdump
AWK     = awk
GENKSYMS    = scripts/genksyms/genksyms
INSTALLKERNEL  := installkernel
DEPMOD      = /sbin/depmod
PERL        = perl
PYTHON      = python
CHECK       = sparse

CHECKFLAGS     := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
          -Wbitwise -Wno-return-void $(CF)
CFLAGS_MODULE   =
AFLAGS_MODULE   =
LDFLAGS_MODULE  =
CFLAGS_KERNEL   =
AFLAGS_KERNEL   =
CFLAGS_GCOV = -fprofile-arcs -ftest-coverage

在这些定义好的变量后面，我们又定义了两个变量：USERINCLUDE和LINUXINCLUDE。他们包含了头文件的路径（第一个是给用户用的，第二个是给内核用的），使用cat Makefile | head -n 387 | tail -n +369 查看

# Use USERINCLUDE when you must reference the UAPI directories only.
USERINCLUDE    := \
        -I$(srctree)/arch/$(hdr-arch)/include/uapi \
        -Iarch/$(hdr-arch)/include/generated/uapi \
        -I$(srctree)/include/uapi \
        -Iinclude/generated/uapi \
                -include $(srctree)/include/linux/kconfig.h

# Use LINUXINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
LINUXINCLUDE    := \
        -I$(srctree)/arch/$(hdr-arch)/include \
        -Iarch/$(hdr-arch)/include/generated/uapi \
        -Iarch/$(hdr-arch)/include/generated \
        $(if $(KBUILD_SRC), -I$(srctree)/include) \
        -Iinclude \
        $(USERINCLUDE)

以及给C编译器的标准标志，使用cat Makefile | head -n 419 | tail -n +387查看

KBUILD_CPPFLAGS := -D__KERNEL__

KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
           -fno-strict-aliasing -fno-common \
           -Werror-implicit-function-declaration \
           -Wno-format-security \
           -std=gnu89

KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS   := -D__ASSEMBLY__
KBUILD_AFLAGS_MODULE  := -DMODULE
KBUILD_CFLAGS_MODULE  := -DMODULE
KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds

# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)

export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP
export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS

export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KASAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS

这并不是最终确定的编译器标志，它们还可以在其他makefile里面更新（比如arch/里面的kbuild）。变量定义完之后，全部会被导出供其他makefile使用。

下面的两个变量RCS_FIND_IGNORE和RCS_TAR_IGNORE包含了被版本控制系统忽略的文件，使用cat Makefile | head -n 432 | tail -n +419 查看

# When compiling out-of-tree modules, put MODVERDIR in the module
# tree rather than in the kernel tree. The kernel tree might
# even be read-only.
export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_versions

# Files to ignore in find ... statements

export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o    \
              -name CVS -o -name .pc -o -name .hg -o -name .git \) \
              -prune -o
export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \
             --exclude CVS --exclude .pc --exclude .hg --exclude .git

然后后面的一大块内容负责根据各种配置文件（make*.config）生成不同目标内核的
可以使用cat Makefile | head -n 593 | tail -n +432 进行查看，内容较多，我们在这里就不一一列举了。
下面让我么直接进入make构建的过程。

内核编译过程

---

现在我们已经完成了所有的配置工作，根makefile的下一步工作就是和编译内核相关的了。
在这之前，我们不会在终端看到make命令输出的任何东西。

但是现在编译的第一步开始了，好吧，我们知道make后，最终的结果叫vmlinux，那我们就找找这个神奇的东西是怎么产生的吧。

终极目标vmlinux

---

这里我们需要从内核根makefile的594行开始，这里可以看到目标vmlinux的构建命令

使用 cat Makefile | head -n 606 | tail -n +594 查看

# The all: target is the default when no target is given on the
# command line.
# This allow a user to issue only 'make' to build a kernel including modules
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux

# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=
ARCH_AFLAGS :=
ARCH_CFLAGS :=
include arch/$(SRCARCH)/Makefile

目标all:是在命令行如果不指定具体目标时默认使用的目标。
你可以看到这里包含了架构相关的makefile（在这里就指的是arch/x86/Makefile）。从这一时刻起，我们会从这个makefile继续进行下去。
如我们所见，目标all依赖于根makefile后面声明的vmlinux，我们可以使用cat Makefile | head -n 922 | tail -n +920 来查看

# Include targets which we want to
# execute if the rest of the kernel build went well.
vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORC

vmlinux是linux内核的静态链接可执行文件格式。脚本scripts/link-vmlinux.sh把不同的编译好的子模块链接到一起形成了vmlinux。

vmlinux-deps

同时我们可以发现vlinux依赖于是vmlinux-deps，我们查找一下它cat -n Makefile | grep vmlinux-deps

发现它定义在914行，内容如下

vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)

它是由内核代码下的每个顶级目录的built-in.o组成的。
之后我们还会检查内核所有的目录，kbuild会编译各个目录下所有的对应$(obj-y)的源文件。接着调用$(LD)-r把这些文件合并到一个build-in.o文件里。当然此时我们还没有vmlinux-deps，所以目标vmlinux现在还不会被构建。对我而言vmlinux-deps包含下面的文件：

arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
arch/x86/kernel/head64.o    arch/x86/kernel/head.o
init/built-in.o             usr/built-in.o
arch/x86/built-in.o         kernel/built-in.o
mm/built-in.o               fs/built-in.o
ipc/built-in.o              security/built-in.o
crypto/built-in.o           block/built-in.o
lib/lib.a                   arch/x86/lib/lib.a
lib/built-in.o              arch/x86/lib/built-in.o
drivers/built-in.o          sound/built-in.o
firmware/built-in.o         arch/x86/pci/built-in.o
arch/x86/power/built-in.o   arch/x86/video/built-in.o
net/built-in.o

vmlinux-dirs

---

内核中有这么多目录，Makefile是怎么知道这些目录的呢，让我们继续往下看，使用cat -n Makefile | head -n 940 | tail -n +936 查看

# The actual objects are generated when descending,
# make sure no implicit rule kicks in
$(sort $(vmlinux-deps)): $(vmlinux-dirs) ;

我们会发现vmlinux-deps是基于vmlinux-dirs
继续往下，使用cat Makefile | head -n 950 | tail -n +940
查看

# Handle descending into subdirectories listed in $(vmlinux-dirs)
# Preset locale variables to speed up the build process. Limit locale
# tweaks to this spot to avoid wrong language settings when running

# make menuconfig etc.

# Error messages still appears in the original language

PHONY += $(vmlinux-dirs)
$(vmlinux-dirs): prepare scripts
    $(Q)$(MAKE) $(build)=$@

就像我们看到的，vmlinux-dir依赖于两部分：prepare和scripts。

prepare

---

第一个prepare定义在内核的根makefile中，准备工作分成三个阶段。

我们继续往下看，使用 cat -n Makefile | head -n 996 | tail -n +959

# Things we need to do before we recursively start building the kernel
# or the modules are listed in "prepare".
# A multi level approach is used. prepareN is processed before prepareN-1.
# archprepare is used in arch Makefiles and when processed asm symlink,
# version.h and scripts_basic is processed / created.

# Listed in dependency order
PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3

# prepare3 is used to check if we are building in a separate output directory,
# and if so do:
# 1) Check that make has not been executed in the kernel src $(srctree)
prepare3: include/config/kernel.release
ifneq ($(KBUILD_SRC),)
    @$(kecho) '  Using $(srctree) as source for kernel'
    $(Q)if [ -f $(srctree)/.config -o -d $(srctree)/include/config ]; then \
        echo >&2 "  $(srctree) is not clean, please run 'make mrproper'"; \
        echo >&2 "  in the '$(srctree)' directory.";\
        /bin/false; \
    fi;
endif

# prepare2 creates a makefile if using a separate output directory
prepare2: prepare3 outputmakefile asm-generic

prepare1: prepare2 $(version_h) include/generated/utsrelease.h \
                   include/config/auto.conf
    $(cmd_crmodverdir)

archprepare: archheaders archscripts prepare1 scripts_basic

prepare0: archprepare FORCE
    $(Q)$(MAKE) $(build)=.

# All the preparing..
prepare: prepare0

第一个prepare0展开到archprepare，后者又展开到archheader和archscripts，这两个变量定义在对应架构目录下的Makefile，x86架构就是arch/x86让我们看看这个文件。
x86特定的makefile从变量定义开始，这些变量都是和特定架构的配置文件(defconfig，等等)有关联。在定义了编译16-bit代码的编译选项之后，根据变量BITS的值，如果是32，汇编代码、链接器、以及其它很多东西（全部的定义都可以在arch/x86/Makefile找到）对应的参数就是i386，而64就对应的是x86_84。

archheaders

首先是archheaders

archheaders:
    $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all

archscripts

接着是archscripts

archscripts: scripts_basic
    $(Q)$(MAKE) $(build)=arch/x86/tools relocs

scripts_basic

然后是scripts_basic
通过查找发现我们可以看到archscripts是依赖于根Makefile里的scripts_basic。


使用cat Makefile | head -n 441 | tail -n +432 查看

#====================================================
# Rules shared between *config targets and build targets

# Basic helpers built in scripts/
PHONY += scripts_basic
scripts_basic:
    $(Q)$(MAKE) $(build)=scripts/basic
    $(Q)rm -f .tmp_quiet_recordmcount

首先我们可以看出scripts_basic是按照scripts/basic的makefile执行make的

下面我们看看scripts/basic下的makefile都有什么

scripts/basic/Makefile包含了编译两个主机程序fixdep和bin2的目标

第一个工具是fixdep：
用来优化gcc生成的依赖列表，然后在重新编译源文件的时候告诉make。
第二个工具是bin2c，
它依赖于内核配置选项CONFIG_BUILD_BIN2C，并且它是一个用来将标准输入接口（LCTT译注：即stdin）收到的二进制流通过标准输出接口（即：stdout）转换成C头文件的非常小的C程序。你可能注意到这里有些奇怪的标志，如hostprogs-y等。这个标志用于所有的kbuild文件，更多的信息你可以从documentation获得。

在我们这里，hostprogs-y告诉kbuild这里有个名为fixed的程序，这个程序会通过和Makefile相同目录的fixdep.c编译而来。

我们make时执行make之后，终端的第一个输出就是kbuild的结果：

现在scripts_basic的工作完成了，现在archscripts 开始工作了，重新回到archscripts的地方，

    $(Q)$(MAKE) $(build)=arch/x86/tools relocs

当目标script_basic被执行，目标archscripts就会make arch/x86/tools下的makefile和目标relocs
包含了重定位的信息的代码relocs_32.c和relocs_64.c将会被编译，这可以在make的输出中看到，下面仍然是make的工作

下面我们继续接着进行make，我们发现在编译完relocs.c之后会检查version.h

使用 cat Makefile | head -n 1021 | tail -n +1017 查看

$(version_h): $(srctree)/Makefile FORCE
    $(call filechk,version.h)
    $(Q)rm -f $(old_version_h)

以及在内核的根Makefiel使用arch/x86/include/generated/asm的目标asm-generic来构建generic汇编头文件。

在目标asm-generic之后，archprepare就完成了，所以目标prepare0会接着被执行，如我上面所写：

prepare0: archprepare FORCE
    $(Q)$(MAKE) $(build)=.

注意build，它是定义在文件scripts/Kbuild.include，内容是这样的：

脚本scripts/Makefile.build通过参数obj给定的目录找到Kbuild文件，然后引入kbuild文件

include $(kbuild-file)

并根据这个构建目标。我们这里.包含了生成kernel/bounds.s和arch/x86/kernel/asm-offsets.s的Kbuild文件。在此之后，目标prepare就完成了它的工作。

scripts

---

vmlinux-dirs也依赖于第二个目标scripts，它会编译接下来的几个程序：filealias，mk_elfconfig，modpost等等。

与prepare类似，所以我们在这里就不细讲了。

开始编译vmlinux-dirs

---

之后，scripts/host-programs就可以开始编译我们的目标vmlinux-dirs了。

首先，我们先来理解一下vmlinux-dirs都包含了那些东西。在我们的例子中它包含了下列内核目录的路径

我们可以在内核的根Makefile里找到vmlinux-dirs的定义：

使用cat -n Makefile | head -n 905 | tail -n +891 查看vmlinux-dirs的定义

vmlinux-dirs    := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
             $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
             $(net-y) $(net-m) $(libs-y) $(libs-m)))

vmlinux-alldirs := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \
             $(init-) $(core-) $(drivers-) $(net-) $(libs-))))

init-y      := $(patsubst %/, %/built-in.o, $(init-y))
core-y      := $(patsubst %/, %/built-in.o, $(core-y))
drivers-y   := $(patsubst %/, %/built-in.o, $(drivers-y))
net-y       := $(patsubst %/, %/built-in.o, $(net-y))
libs-y1     := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2     := $(patsubst %/, %/built-in.o, $(libs-y))
libs-y      := $(libs-y1) $(libs-y2)

前面我们已经知道vmlinux-dir会依赖与prepare和scripts

$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@

符号$@在这里代表了vmlinux-dirs，这就表明程序会递归遍历从vmlinux-dirs以及它内部的全部目录（依赖于配置），并且在对应的目录下执行make命令。我们可以在输出看到结果

在make的最后阶段，当所有的目录编译结束后，每个目录下的源代码将会被编译并且链接到built-io.o里。

神秘的built-in.o

---

在最后的链接过程中，我们可以看到，几乎所有的依赖条件中，都会生成一个built-in.o的文件。 那这个文件，是怎么生成的呢？

生成vmlinux

---

那么问题来了，makefile是怎么把内核目录中编译生成的build-in.o链接在一起生成vmlinux的呢？
现在我们回到目标vmlinux上。你应该还记得，目标vmlinux是在内核的根makefile里。在链接vmlinux之前，系统会构建samples,Documentation等等。
接着我们使用cat -n Makefile | head -n 936 | tail -n +922 查看

vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE
ifdef CONFIG_HEADERS_CHECK
    $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
endif
ifdef CONFIG_SAMPLES
    $(Q)$(MAKE) $(build)=samples
endif
ifdef CONFIG_BUILD_DOCSRC
    $(Q)$(MAKE) $(build)=Documentation
endif
ifdef CONFIG_GDB_SCRIPTS
    $(Q)ln -fsn `cd $(srctree) && /bin/pwd`/scripts/gdb/vmlinux-gdb.py
endif
    +$(call if_changed,link-vmlinux)

我们可以看到vmlinux依赖于$(vmlinux-deps) 但是还需要一个shell脚本scripts/link-vmlinux.sh 这个脚本是用来干嘛的，不急我们慢慢来。
我们直接看最后使用+$(call if_changed,link-vmlinux)，真相正在一步步浮出水面。

我们查看一下这个命令

这个命令是cmd_link-vmlinux，就定义在主Makefile中第917行

cmd_link-vmlinux = $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)

(CONFIGSHELL)就是我们的bashshell

< 表示第一个以来目标，那么在vmlinux目标中，第一个目标是 scripts/link-vmlinux.sh
那么这个命令展开就成为

/bin/bash scripts/link-vmlinux.sh ld -m elf_i386 --emit-relocs --build-id

现在明晰了在这里调用脚本scripts/link-vmlinux.sh的，把所有的built-in.o链接成一个静态可执行文件vmlinux，和生成System.map。
那么link-vmlinux.sh是怎么做到得呢，使用该cat -n link-vmlinux.sh | head -n 239 | tail -n +229 查看这个脚本的信息

info LD vmlinux
vmlinux_link "${kallsymso}" vmlinux

if [ -n "${CONFIG_BUILDTIME_EXTABLE_SORT}" ]; then
    info SORTEX vmlinux
    sortextable vmlinux
fi

info SYSMAP System.map
mksysmap vmlinux System.map

使用了脚本中vmlinux_link这个函数来生成vmlinux，使用mksysmap生成System.map
下面是vmlinux_link 函数的定义，cat -n link-vmlinux.sh | head -n 69 | tail -n +51


vmlinux_link()
{
    local lds="${objtree}/${KBUILD_LDS}"

    if [ "${SRCARCH}" != "um" ]; then
        ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2}                  \
            -T ${lds} ${KBUILD_VMLINUX_INIT}                     \
            --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
    else
        ${CC} ${CFLAGS_vmlinux} -o ${2}                              \
            -Wl,-T,${lds} ${KBUILD_VMLINUX_INIT}                 \
            -Wl,--start-group                                    \
                 ${KBUILD_VMLINUX_MAIN}                      \
            -Wl,--end-group                                      \
            -lutil ${1}
        rm -f linux
    fi
}

然后是mksysmap，使用cat -n link-vmlinux.sh | head -n 107 | tail -n +103 查看

mksysmap()
{
    ${CONFIG_SHELL} "${srctree}/scripts/mksysmap" ${1} ${2}
}

最后我们来看看下面的输出：

vmlinux和System.map生成在内核源码树根目录下。

这就是全部了，vmlinux构建好了，下一步就是创建bzImage.

构建bzImage

---

bzImage就是压缩了的linux内核镜像。我们可以在构建了vmlinux之后通过执行makebzImage获得bzImage。同时我们可以仅仅执行make而不带任何参数也可以生成bzImage，因为它是在arch/x86/kernel/Makefile里预定义的、默认生成的镜像。

我们在makefile中查找一下

我们可以看到bzImage是依赖于vmlinux生成的，

我们使用cat -n Makefile | head -n 237 | tail -n +215 查看其构建信息

####
# boot loader support. Several targets are kept for legacy purposes

boot := arch/x86/boot

BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage

PHONY += bzImage $(BOOT_TARGETS)

# Default kernel to build
all: bzImage

# KBUILD_IMAGE specify target image being built
KBUILD_IMAGE := $(boot)/bzImage

bzImage: vmlinux
ifeq ($(CONFIG_X86_DECODER_SELFTEST),y)
    $(Q)$(MAKE) $(build)=arch/x86/tools posttest
endif
    $(Q)$(MAKE) $(build)=$(boot) $(KBUILD_IMAGE)
    $(Q)mkdir -p $(objtree)/arch/$(UTS_MACHINE)/boot
    $(Q)ln -fsn ../../x86/boot/bzImage $(objtree)/arch/$(UTS_MACHINE)/boot/$@

setup.bin

---

在这里我们可以看到第一次为$(boot)==arch/x86/boot 目录执行了make 操作

我们进入这个目录看看。这个makefile是如何工作生成bzImage的

我们会发现bzImage依赖于setup.bin和vmlinux.bin
使用cat -n Makefile | head -n 112 | tail -n +107 我们可以查看到

$(obj)/setup.bin: $(obj)/setup.elf FORCE
    $(call if_changed,objcopy)

$(obj)/compressed/vmlinux: FORCE
    $(Q)$(MAKE) $(build)=$(obj)/compressed $@

那么我们现在的主要目标是编译目录arch/x86/boot和arch/x86/boot/compressed的代码，构建setup.bin和vmlinux.bin，最后用这两个文件生成bzImage。

第一个目标是定义在arch/x86/boot/Makefile的$(obj)/setup.elf:

我们接着使用cat -n Makefile | head -n 105 | tail -n +103 查看如何生成setup.elf

$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
    $(call if_changed,ld)

通过setup.ld来检列所有的setup_objs的目标文件来生成setup.elf

vmlinux.bin

---

下一个源码文件是arch/x86/boot/header.S，这个是一个汇编文件

但是我们不能现在就编译它，因为这个目标依赖于下面两个头文件：

$(obj)/header.o: $(obj)/voffset.h $(obj)/zoffset.h

第一个头文件voffset.h是使用sed脚本生成的

包含用nm工具从vmlinux获取的两个地址：

#define VO__end 0xffffffff82ab0000
#define VO__text 0xffffffff81000000

这两个地址是内核的起始和结束地址。

第二个头文件zoffset.h在arch/x86/boot/compressed/Makefile可以看出是依赖于目标vmlinux的

$(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE
    $(call if_changed,zoffset)

然后编译目录arch/x86/boot/compressed下的源代码，然后生成vmlinux.bin、vmlinux.bin.bz2，和编译工具mkpiggy。

vmlinux.bin是去掉了调试信息和注释的vmlinux二进制文件，加上了占用了u32（LCTT译注：即4-Byte）的长度信息的vmlinux.bin.all压缩后就是vmlinux.bin.bz2。其中vmlinux.bin.all包含了vmlinux.bin和vmlinux.relocs（LCTT译注：vmlinux的重定位信息），其中vmlinux.relocs是vmlinux经过程序relocs处理之后的vmlinux镜像（见上文所述）。

我们现在已经获取到了这些文件，汇编文件piggy.S将会被mkpiggy生成、然后编译：

MKPIGGY arch/x86/boot/compressed/piggy.S
 AS      arch/x86/boot/compressed/piggy.o

这个汇编文件会包含经过计算得来的、压缩内核的偏移信息。处理完这个汇编文件，我们就可以看到zoffset生成了：

ZOFFSET arch/x86/boot/zoffset.h

现在zoffset.h和voffset.h已经生成了，arch/x86/boot里的源文件可以继续编译，直到
所有的源代码会被编译，他们最终会被链接到setup.elf

ld -m elf_x86_64   -T arch/x86/boot/setup.ld arch/x86/boot/a20.o arch/x86/boot/bioscall.o arch/x86/boot/cmdline.o arch/x86/boot/copy.o arch/x86/boot/cpu.o arch/x86/boot/cpuflags.o arch/x86/boot/cpucheck.o arch/x86/boot/early_serial_console.o arch/x86/boot/edd.o arch/x86/boot/header.o arch/x86/boot/main.o arch/x86/boot/mca.o arch/x86/boot/memory.o arch/x86/boot/pm.o arch/x86/boot/pmjump.o arch/x86/boot/printf.o arch/x86/boot/regs.o arch/x86/boot/string.o arch/x86/boot/tty.o arch/x86/boot/video.o arch/x86/boot/video-mode.o arch/x86/boot/version.o arch/x86/boot/video-vga.o arch/x86/boot/video-vesa.o arch/x86/boot/video-bios.o -o arch/x86/boot/setup.elf

最后的两件事是创建包含目录arch/x86/boot/*下的编译过的代码的setup.bin：

objcopy  -O binary arch/x86/boot/setup.elf arch/x86/boot/setup.bin

以及从vmlinux生成vmlinux.bin:

objcopy  -O binary -R .note -R .comment -S arch/x86/boot/compressed/vmlinux arch/x86/boot/vmlinux.bin

生成bzImage

---

最后，我们编译主机程序arch/x86/boot/tools/build.c，它将会用来把setup.bin和vmlinux.bin打包成bzImage:

arch/x86/boot/tools/build arch/x86/boot/setup.bin arch/x86/boot/vmlinux.bin arch/x86/boot/zoffset.h arch/x86/boot/bzImage

实际上bzImage就是把setup.bin和vmlinux.bin连接到一起。最终我们会看到输出结果，就和那些用源码编译过内核的同行的结果一样：