Linux内核学习摘录

LINUX

系统初始化 —— 内核引导程序

initrd是一种基于内存的文件系统，启动过程中，系统在访问真正的根文件系统时，会先访问initrd文件系统。比如，使用的是scsi硬盘，而内核vmlinuz中并没有这个scsi硬件的驱动，那么在装入scsi模块之前，内核不能加载根文件系统，但scsi模块存储在根文件系统的/lib/modules下。为了解决这个问题，能引导一个能够读实际内核的initrd内核并用initrd修正scsi引导问题。initrd-2.6.18-194.el5.img是用gzip压缩的文件，initrd实现加载一些模块和安装文件系统等功能。

initrd的作用在于解决一个矛盾：即内核想访问真正的根文件系统，如在硬盘上，但是内核中并没有硬盘的驱动，驱动存储在根文件系统中，因此这形成了一种相互依赖却没办法解开的循环。initrd打破了这种循环，它能提供硬盘的驱动，在内核访问文件系统之前，将文件系统安装好。

内核映像的形成 —— KBuild体系（一）

Kbuild Makefile的最核心的部分是内核目标的定义。主要是定义需要编译的文件，所有的选项，以及到哪些子目录去执行递归操作。
例如，源代码某目录中有一个foo.c，要编译成一对象，那么该目录中的Kbuild Makefile其中必有一行形式如下：
obj-$(CONFIG_FOO) += foo.o
$(CONFIG_FOO)来自.config内核配置文件，可以为y(编译进内核) 或m(编译成模块)。如果CONFIG_FOO不是y和m，那么该文件就不会被编译联接了。

（1）编译进内核
Kbuild Makefile 规定所有编译进内核的目标文件都存在$(obj-y)列表中。而这些列表依赖内核的配置。
Kbuild编译所有的$(obj-y)文件。然后，调用"$(LD) -r"将它们合并到一个build-in.o文件中。稍后，该build-in.o会被顶层Makefile链接进vmlinux中。
注意，$(obj-y)中的文件是有顺序的。列表中有重复项是可以的，因为当第一个文件被联接到built-in.o中后，其余文件就被忽略了。
另外，链接也是有顺序的，那是因为有些函数(module_init()/__initcall)将会在启动时按照他们出现的顺序进行调用。所以，记住改变链接的顺序可能改变你系统顺序，从而导致你的硬件损害，这一点千万要注意。
（2）编译成模块
编译成模块和内核的区别不用我多说，因为模块是可装载，通过insmod等命令。$(obj-m) 列举出了哪些文件要编译成可装载模块。一个模块可以由一个文件或多个文件编译而成。如果是一个源文件，KbuildMakefile只需简单的将其加到$(obj-m)中去就可以了。
如果内核模块是由多个源文件编译而成，那你就要采用一个方法去声明你所要编译的模块：
obj-$(CONFIG_FOO) += isdn.o
解释一下这个方法，很简单，Kbuild需要知道你所编译的模块是基于哪些文件，所以你需要通过变量$(<module_name>-objs)来告诉它：

#drivers/isdn/i4l/Makefile(表示以下是这个文件里面部分内容)
obj-$(CONFIG_ FOO) += isdn.o
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o

上面的例子中，isdn.o就是模块名，Kbuild将编译在$(isdn-objs)中列出的所有文件，然后使用"$(LD) -r"生成isdn.o。
Kbuild能够识别用于组成目标文件的后缀-objs和后缀-y。这就让KbuildMakefile可以通过使用 CONFIG_ 符号来判断该对象是否是用来组合对象的：

#fs/ext2/Makefile
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o bitmap.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o

在这个例子中，如果 $(CONFIG_EXT2_FS_XATTR) 是 'y'，xattr.o将是复合对象 ext2.o的一部分。
注意：当然，当你要将其编译进内核时，上面的语法同样适用。所以，如果你的 CONFIG＿EXT2＿FS=y，那Kbuild会按你所期望的那样，生成 ext2.o文件，然后将其联接到 built-in.o中。

（4）递归向下访问目录
一个Kbuild Makefile只对编译所在目录的对象负责。在子目录中的文件的编译要由其所在的子目录的Makefile来管理。只要你让Kbuild知道它应该递归操作，那么该系统就会在其子目录中自动的调用 make 递归操作。这就是obj-y 和 obj-m 的作用。
例如，ext2 被放的一个单独的目录下，在fs目录下的Makefile会告诉Kbuild使用下面的赋值进行向下递归操作：

#fs/Makefile
obj-$(CONFIG_EXT2_FS) += ext2/

如果 CONFIG_EXT2_FS 被设置为 'y'(编译进内核)或是'm'(编译成模块)，相应的 obj- 变量就会被设置，并且Kbuild就会递归向下访问 ext2 目录。Kbuild只是用这些信息来决定它是否需要访问该目录，而具体怎么编译由该目录中的Makefile来决定。
注意，将CONFIG_变量设置成目录名是一个好的编程习惯。这让Kbuild在完全忽略那些相应的CONFIG_值不是'y'和'm'的目录。

内核映像的形成 —— KBuild体系（三）

KBuild体系还有一个重要的概念，那就是编译标志。我们可以在一些Makefile中看到如下标志：
EXTRA_CFLAGS、 EXTRA_AFLAGS、 EXTRA_LDFLAGS、EXTRA_ARFLAGS
这些EXTRA_开头的大写字母变量都是编译标志，所有的 EXTRA_ 变量只在所定义的Kbuild Makefile中起作用。EXTRA_ 变量可以在Kbuild Makefile中所有命令中使用。
$(EXTRA_CFLAGS) 是用 $(CC) 编译C源文件时的选项，例如：

# drivers/sound/emu10kl/Makefile
EXTRA_CFLAGS += -I$(obj)
ifdef DEBUG
EXTRA_CFLAGS += -DEMU10KL_DEBUG
endif

由于顶层Makefile的$(CC)拥有变量 $(CFLAGS) 用来作为整个源代码树的编译选项，所以在这里做这么一个设置就是将$(CFLAGS)替换成EXTRA_CFLAGS。

内核映像的形成——链接vmlinux

在2.6内核中，为了更好地调试内核，引入了kallsyms 。kallsyms 抽取内核用到的所有函数地址(全局的，静态的)和非栈数据变量地址，生成一个数据小块( data blog )，作为只读数据链接进kernel image 。相当于内核中存在了一份System.map .内核可以根据符号名查出函数的地址。当系统发生oops 时，（不懂oops？好吧，内核崩溃总懂了吧）kallsyms的print_symbol 函数会显示相关信息，以此形式跟踪栈的状态。

内核映像的形成——制作bzImage

我们知道，C和汇编源文件被编译成ELF 文件后，通常会包含有连接器（Linker）或加载器（Loader）所需要的ELF header，Program header table或Section header table。这些ELF header 和一些section 的作用是告诉内核ELF Loader 如何载入ELF 可执行文件。但是， Linux内核作为一种特殊的ELF 文件，没有ELF Loader的帮助，需要特殊辅助程序去装载它。它的装载地址是固定的，前面讲了的，0xC0100000。
这时，为了保证通用性而存在的ELF header 和一些section对内核的装载就没有意义了。为了使内核尽可能小，可以把这些信息去掉。所以通常采用objcopy命令来去掉原来ELF文件中的header和section，同时转化为raw binary格式的文件。即便如此，通过objcopy 处理过的vmlinux 一般需要压缩以后再重新链接，当然必须把解压缩的程序也同时链接进来。
这个压缩的过程着实奇怪：压缩后，然后再解压缩，岂不是浪费启动时间？这还是因为当x86系列处理器启动初期，处于实模式状态，可以寻得的地址空间十分有限，仅仅是1MB，如果内核过大，就无法加载。更新的内核（从2.6.30开始）甚至提供了更高压缩率的格式：bzip或LZMA。