日志
linux2.6内核Makefile详解
熟悉内核的Makefile对开发设备驱动、理解内核代码结构都是非常重要的
linux2.6内核Makefile的许多特性和2.4内核差别很大，在内核目录的documention/kbuild/makefiles.txt中有详细的说明。给大家一个中文版的翻译
=== 1 概述
=== 2 用户与作用
=== 3 Kbuild文件
--- 3.1 目标定义
--- 3.2 编译进内核 - obj-y
--- 3.3 编译可装载模块 - obj-m
--- 3.4 输出的符号
--- 3.5 目标库文件 - lib-y
--- 3.6 递归躺下访问目录
--- 3.7 编辑标志
--- 3.8 命令行的依赖关系(原文中没有写:-))
--- 3.9 跟踪依赖
--- 3.10 特殊规则
--- 3.11 $(CC) 支持的函数
=== 4 本机程序支持
--- 4.1 简单的本机程序
--- 4.2 复合的本机程序
--- 4.3 定义共享库
--- 4.4 使用用C++编写的本机程序
--- 4.5 控制本机程序的编译选项
--- 4.6 编译主机程序时
--- 4.7 使用 hostprogs-$(CONFIG_FOO)
=== 5 Kbuild清理
=== 6 架构Makefile
--- 6.1 调整针对某一具体架构生成的镜像
--- 6.2 将所需文件加到 archprepare 中
--- 6.3 递归下向时要访问的目录列表
--- 6.4 具体架构的启动镜像
--- 6.5 构造非Kbuild目标
--- 6.6 构建启动镜像的命令
--- 6.7 Kbuild自定义命令
--- 6.8 联接器预处理脚本
=== 7 Kbuild 变量
=== 8 Makefile语言
=== 9 关于作者
=== 10 TODO
=== 1 概述
Linux内核的Makefile分为5个部分：
Makefile 顶层Makefile
.config 内核配置文件
arch/$(ARCH)/Makefile 具体架构的Makefile
scripts/Makefile.* 通用的规则等。面向所有的Kbuild Makefiles。
kbuild Makefiles 内核源代码中大约有500个这样的文件
顶层Makefile阅读的.config文件，而该文件是由内核配置程序生成的。
顶层Makefile负责制作：vmlinux(内核文件)与模块(任何模块文件)。制作的过程主要是
通过递归向下访问子目录的形式完成。并根据内核配置文件确定访问哪些子目录。顶层
Makefile要原封不动的包含一具体架构的Makefile，其名字类似于 arch/$(ARCH)/
Makefile。该架构Makefile向顶层Makefile提供其架构的特别信息。
每一个子目录都有一个Kbuild Makefile文件，用来执行从其上层目录传递下来的命令。
Kbuild Makefile从.config文件中提取信息，生成Kbuild完成内核编译所需的文件列表。
scripts/Makefile.*包含了所有的定义、规则等信息。这些文件被用来编译基于kbuild
Makefile的内核。(**有点不通**)
=== 2 用户与作用
可以将人们与内核Makefile的关系分成4类。
*使用者* 编译内核的人。他们只是键入"make menuconfig"或"make"这样的命令。一般
情况下是不会读或编辑任何内核Makefile（或者任何的源文件）。
*普通开发人员* 这是一群工作在内核某一功能上的人，比如：驱动开发，文件系统或
网络协议。他们所需要维护的只是他们所工作的子系统的Kbuild Makefile。为了提高
工作的效率，他们也需要对内核Makefile有一个全面的认识，并且要熟悉Kbuild的接口
。
*架构开发人员* 这是一些工作在具体架构，比如sparc 或者ia64，上面的人。架构开
发者需要在熟悉kbuild Makefile的同时，也要熟悉他所工作架构的Makefile。
*Kbuild开发者* 维护Kbuild系统的人。他们需要知晓内核Makefile的方方面面。
该文件是为普通开发人员与架构开发人员所写。
=== 3 Kbuild文件
大部分内核中的Makefile都是使用Kbuild组织结构的Kbuild Makefile。这章介绍了
Kbuild Makefile的语法。
Kbuild文件倾向于"Makefile"这个名字，"Kbuild"也是可以用的。但如果"Makefile"
"Kbuild"同时出现的话，使用的将会是"Kbuild"文件。
3.1节 目标定义是一个快速介绍，以后的几章会提供更详细的内容以及实例。
--- 3.1 目标定义
目标定义是Kbuild Makefile的主要部分，也是核心部分。主要是定义了要编
译的文件，所有的选项，以及到哪些子目录去执行递归操作。
最简单的Kbuild makefile 只包含一行：
例子：
obj-y += foo.o
该例子告诉Kbuild在这目录里，有一个名为foo.o的目标文件。foo.o将从foo.c
或foo.S文件编译得到。
如果foo.o要编译成一模块，那就要用obj-m了。所采用的形式如下：
例子：
obj-$(CONFIG_FOO) += foo.o
$(CONFIG_FOO)可以为y(编译进内核) 或m(编译成模块)。如果CONFIG_FOO不是y
和m,那么该文件就不会被编译联接了。
--- 3.2 编译进内核 - obj-y
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)将会在启
动时按照他们出现的顺序进行调用。所以，记住改变联接的顺序可能改变你
SCSI控制器的检测顺序，从而导致你的硬盘数据损害。
例子：
#drivers/isdn/i4l/Makefile
# Makefile for the kernel ISDN subsystem and device drivers.
# Each configuration option enables a list of files.
obj-$(CONFIG_ISDN) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 编译可装载模块 - obj-m
$(obj-m) 列举出了哪些文件要编译成可装载模块。
一个模块可以由一个文件或多个文件编译而成。如果是一个源文件，Kbuild
Makefile只需简单的将其加到$(obj-m)中去就可以了。
例子：
#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
注意：此例中 $(CONFIG_ISDN_PPP_BSDCOMP) 的值为'm'
如果内核模块是由多个源文件编译而成，那你就要采用上面那个例子一样的
方法去声明你所要编译的模块。
Kbuild需要知道你所编译的模块是基于哪些文件，所以你需要通过变量
$(<module_name>-objs)来告诉它。
例子：
#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN) += 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。这就让Kbuild
Makefile可以通过使用 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中。
--- 3.4 输出的符号
在Makefile中,没有对模块输出的符号有特殊要求。
--- 3.5 目标库文件 - lib-y
在 obj-* 中所列文件是用来编译模块或者是联接到特定目录中的 built-in.o
。同样，也可以列出一些将被包含在lib.a库中的文件。
在 lib-y 中所列出的文件用来组成该目录下的一个库文件。
在 obj-y 与 lib-y 中同时列出的文件，因为都是可以访问的，所以该文件是
不会被包含在库文件中的。
同样的情况， lib-m 中的文件就要包含在 lib.a 库文件中。
注意，一个Kbuild makefile可以同时列出要编译进内核的文件与要编译成库
的文件。所以，在一个目录里可以同时存在 built-in.o 与 lib.a 两个文件。
例子：
#arch/i386/lib/Makefile
lib-y := chechsum.o delay.o
这将由 checksum.o 和delay.o 两个文件创建一个库文件 lib.a。为了让
Kbuild 真正认识到这里要有一个库文件 lib.a 要创建，其所在的目录要加
到 libs-y 列表中。
还可参考"6.3 递归下向时要访问的目录列表"
lib-y 使用一般限制在 lib/ 和 arch/*/lib 中。
--- 3.6 递归向下访问目录
一个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'的目录。
--- 3.7 编辑标志
EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS
所有的 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拥有变量 $(CFLAGS) 并用来作为整个源
代码树的编译选项。
$(EXTRA_AFLAGS) 也是一个针对每个目录的选项，只不过它是用来编译汇编
源代码的。
例子：
#arch/x86_64/kernel/Makefile
EXTRA_AFLAGS := -traditional
$(EXTRA_LDFLAGS) 和 $(EXTRA_ARFLAGS)分别与 $(LD)和 $(AR)类似，只不
过，他们是针对每个目录的。
例子：
#arch/m68k/fpsp040/Makefile
EXTRA_LDFLAGS := -x
CFLAGS_$@, AFLSGA_$@
CFLAGS_$@ 和 AFLAGS_$@ 只能在当前Kbuild Makefile中的命令中使用。
$(CFLAGS_$@) 是 $(CC) 针对每个文件的选项。$@ 表明了具体操作的文件。
例子：
# drivers/scsi/Makefile
CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
-DGDTH_STATISTICS
CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
以上三行分别设置了aha152x.o,gdth.o 和 seagate.o的编辑选项。
$(AFLAGS_$@) 也类似，只不是是针对汇编语言的。
例子：
# arch/arm/kernel/Makefile
AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
--- 3.9 跟踪依赖
Kbuild 跟踪在以下方面依赖：
1) 所有要参与编译的文件(所有的.c 和.h文件)
2) 在参与编译文件中所要使用的 CONFIG_ 选项
3) 用于编译目标的命令行
因此，如果你改变了 $(CC) 的选项，所有受影响的文件都要重新编译。
--- 3.10 特殊规则
特殊规则就是那Kbuild架构不能提供所要求的支持时，所使用的规则。一个
典型的例子就是在构建过程中生成的头文件。
另一个例子就是那些需要采用特殊规则来准备启动镜像。
特殊规则的写法与普通Make规则一样。
Kbuild并不在Makefile所在的目录执行，所以所有的特殊规则都要提供参与
编译的文件和目标文件的相对路径。
在定义特殊规则时，要使用以下两个变量：
$(src)
$(src) 表明Makefile所在目录的相对路径。经常在定位源代码树中的文件时
，使用该变量。
$(obj)
$(obj) 表明目标文件所要存储目录的相对路径。经常在定位所生成的文件时
，使用该变量。
例子：
#drivers/scsi/Makefile
$(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl
$(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl
这就是一个特殊规则，遵守着make所要求的普通语法。
目标文件依赖于两个源文件。用$(obj)来定位目标文件，用$(src)来定位源文
件(因为它们不是我们生成的文件)。
--- 3.11 $(CC) 支持的函数
内核可能由多个不同版本的$(CC)编译，而每个版本都支持一不同的功能集与
选项集。Kbuild提供了检查 $(CC) 可用选项的基本功能。$(CC)一般情况下是
gcc编译器，但也可以使用其它编译器来代替gcc。
as-option
as-option，当编译汇编文件(*.S)时，用来检查 $(CC) 是否支持特定选项。如
果第一个选项不支持的话，可选的第二个选项可以用来指定。
例子：
#arch/sh/Makefile
cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
在上面的例子里，如果 $(CC) 支持选项 -Wa$(comma)-isa=$(isa-y)，
cflags-y就会被赋予该值。
第二个参数是可选的，当第一个参数不支持时，就会使用该值。
ld-option
ld-option，当联接目标文件时，用来检查 $(CC) 是否支持特定选项。如果第
一个选项不支持的话，可选的第二个选项可以用来指定。
例子：
#arch/i386/kernel/Makefile
vsyscall-flags += $(call ld-option, -Wl$(comma)--hash-style=sysv)
在上面的例子中，如果 $(CC)支持选项 -Wl$(comma)--hash-style=sysv，
ld-option就会被赋予该值。
第二个参数是可选的，当第一个参数不支持时，就会使用该值。
cc-option
cc-option，用来检查 $(CC) 是否支持特定选项,并且不支持使用可选的第二
项。
例子：
#arch/i386/Makefile
cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
在上面的例子中，如果 $(CC)支持选项 -march=pentium-mmx，cc-option就
会被赋予该值，否则就赋 -march-i586。
cc-option的第二个参数是可选的。如果忽略的话，当第一个选项不支持时，
cflags-y 不会被赋值。
cc-option-yn
cc-option-yn,用来检查 gcc 是否支持特定选项，返回'y'支持，否则为'n'。
例子：
#arch/ppc/Makefile
biarch := $(call cc-option-yn, -m32)
aflags-$(biarch) += -a32
cflags-$(biarch) += -m32
在上面的例子里，当 $(CC) 支持 -m32选项时，$(biarch)设置为y。当
$(biarch) 为y时，扩展的 $(aflags-y) 和 $(cflags-y)变量就会被赋值为
-a32 和 -m32。
cc-option-align
gcc版本大于3.0时，改变了函数，循环等用来声明内存对齐的选项。当用到
对齐选项时，$(cc-option-align) 用来选择正确的前缀：
gcc < 3.00
cc-option-align = -malign
gcc >= 3.00
cc-option-align = -falign
例子：
CFLAGS += $(cc-option-align)-functions=4
在上面的例子中，选项 -falign-funcions=4 被用在gcc >= 3.00的时候。对
于小于3.00时， 使用 -malign-funcions=4 。
cc-version
cc-version以数学形式返回 $(CC) 编译器的版本号。
其格式是：<major><minor>，二者都是数学。比如，gcc 3.41 会返回 0341。
当某版本的 $(CC) 在某方面有缺陷时,cc-version就会很有用。比如，选项
-mregparm=3 虽然会被gcc接受，但其实现是有问题的。
例子：
#arch/i386/Makefile
cflags-y += $(shell \
if [ $(call cc-version) -ge 0300 ] ; then \
echo "-meregparm=3"; fi ;)
在上面的例子中，-mregparm=3只会在gcc的版本号大于等于3.0的时候使用。
cc-ifversion
cc-ifversion测试 $(CC) 的版本号，如果版本表达式为真，就赋值为最后的
参数。
例子：
#fs/reiserfs/Makefile
EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0402, -O1)
在这个例子中，如果 $(CC) 的版本小于4.2,EXTRA_CFLAGS就被赋值 -O1。
cc－ifversion 可使用所有的shell 操作符：-eq,-ne,-lt,-le,-gt,和-ge。
第三个参数可以像上面例子一样是个文本，但也可以是个扩展的变量或宏。
/*这段翻译的不好*/
=== 4 本机程序支持
Kbuild 支持编译那些将在编译阶段使用的可执行文件。
为了使用该可执行文件，要将编译分成二个阶段。
第一阶段是告诉Kbuild存在哪些可执行文件。这是通过变量 hostprogs-y来完成的。
第二阶段是添加一个对可执行文件的显性依赖。有两种方法:增加依赖关系到一个规则
中，或是利用变量 $(always)。
以下是详细叙述.
--- 4.1 简单的本机程序
在编译内核时，有时会需要编译并运行一个程序。
下面这行就告诉了kbuild，程序bin2hex应该在本机上编译。
例子：
hostprogs-y := bin2hex
在上面的例子中，Kbuild假设bin2hex是由一个与其在同一目录下，名为
bin2hex.c 的C语言源文件编译而成的。
--- 4.2 复合的本机程序
本机程序可以由多个文件编译而成。
所使用的语法与内核的相应语法很相似。
$(<executeable>-objs) 列出了联接成最后的可执行文件所需的所有目标文件。
例子：
#scripts/lxdialog/Makefile
hostprogs-y := lxdialog
lxdialog-objs := checklist.o lxdialog.o
扩展名为.o的文件是从相应的.c文件编译而来的。在上面的例子中，
checklist.c 编译成了checklist.o，lxdialog.c编译成了lxdialog.o。
最后，两个.o文件联接成了一可执行文件，lxdialog。
注意：语法 <executable>-y不是只能用来生成本机程序。
--- 4.3 定义共享库
扩展名为so的文件称为共享库，被编译成位置无关对象。
Kbuild也支持共享库，但共享库的使用很有限。
在下面的例子中，libconfig.so共享库用来联接到可执行文件 conf中。
例子：
#scripts/kconfig/Makefile
hostprogs-y := conf
conf-objs := conf.o libkconfig.so
libkcofig-objs := expr.o type.o
共享库文件经常要求一个相应的 -objs，在上面的例子中，共享库libkconfig
是由 expr.o 和 type.o两个文件组成的。
expr.o 和 type.o 将被编译成位置无关码，然后联接成共享库文件
libkconfig.so。C++并不支持共享库。
--- 4.4 使用用C++编写的本机程序
kbuild也支持用C++编写的本机程序。在此专门介绍是为了支持kconfig，并且
在一般情况下不推荐使用。
例子：
#scripts/kconfig/Makefile
hostprogs-y := qconf
qconf-cxxobjs := qconf.o
在上面的例子中，可执行文件是由C++文件 qconf.cc编译而成的，由
$(qconf-cxxobjs)来标识。
如果qconf是由.c和.cc一起编译的，那么就需要专门来标识这些文件了。
例子：
#scripts/kconfig/Makefile
hostprogs-y := qconf
qconf-cxxobjs := qconf.o
qconf-objs := check.o
--- 4.5 控制本机程序的编译选项
当编译本机程序时，有可能使用到特殊选项。程序经常是利用$(HOSTCC)编译
,其选项在 $(HOSTCFLAGS)变量中。
可通过使用变量 HOST＿EXTRACFLAGS，影响所有在Makefile文件中要创建的
主机程序。
例子：
#scripts/lxdialog/Makefile
HOST_EXTRACFLAGS += -I/usr/include/ncurses
为一单个文件设置选项，可按形式进行：
例子：
#arch/ppc64/boot/Makefile
HOSTCFLAGS_pinggyback.o := -DKERNELBASE=$(KERNELBASE)
同样也可以给联接器声明一特殊选项。
例子：
#scripts/kconfig/Makefile
HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
当联接qconf时，将会向联接器传递附加选项 "-L$(QTDIR)/lib"。
--- 4.6 编译主机程序时
Kbuild只在需要时编译主机程序。
有两种方法：
(1) 在一具体的规则中显性列出所需要的文件
例子：
#drivers/pci/Makefile
hostprogs-y := gen-devlist
$(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
( cd $(obj); ./gen-devlist ) < $<
目标 $(obj)/devlist.h 是不会在 $(obj)/gen-devlist 更新之前编译的。注意
在该规则中所有有关主机程序的命令必须以$(obj)开头。
(2) 使用 $(always)
当Makefile要编译主机程序，但没有适合的规则时，使用 $(always)。
例子：
#scripts/lxdialog/Makefile
hostprogs-y := lxdialog
always := $(hostprogs-y)
这就是告诉Kbuild，即使没有在规则中声明，也要编译 lxdialog。
--- 4.7 使用 hostprogs-$(CONFIG_FOO)
一个典型的Kbuild模式如下：
例子：
#scripts/Makefile
hostprogs-$(CONFIG_KALLSYMS) += kallsyms
Kbuild 知道 'y' 是编译进内核，而 'm' 是编译成模块。所以，如果配置符号
是'm'，Kbuild仍然会编译它。换句话说，Kbuild处理 hostprogs-m 与
hostprogs-y 的方式是完全一致的。只是，如果不用 CONFIG，最好用
hostprogs-y。
=== 5 Kbuild清理(clean)
"make clean"删除几乎所有的在编译内核时生成的文件，包括了主机程序在内。
Kbuild 通过列表 $(hostprogs-y)，$(hostprogs-m)，$(always)，$(extra-y) 和
$(targets) 知道所要编译的目标。这些目标文件都会被 "make clean" 删除。另外
，在"make clean"还会删除匹配 "*.[oas]"，"*.ko" 的文件，以及由 Kbuild生成
的辅助文件。
辅助文件由 Kbuild Makefile 中的 $(clean-files) 指明。
例子：
#drivers/pci/Makefile
clean-files := devlist.h classlist.h
当执行 "make clean" 时，"devlist.h classlist.h"这两个文件将被删除。如果不使用
绝对路径(路径以'/'开头)的话，Kbuild假设所要删除的文件与Makefile在同一个相对路
径上。
要删除一目录：
例子：
#scripts/package/Makefile
clean-dirs := $(objtree)/debian/
这就会删除目录 debian，包括其所有的子目录。如果不使用绝对路径(路径以'/'开头)的
话，Kbuild假设所要删除的目录与Makefile在同一个相对路径上。
一般情况下，Kbuild会根据 "obj-* := dir/" 递归访问其子目录，但有的时候，Kbuild
架构还不足以描述所有的情况时，还要显式的指明所要访问的子目录。
例子：
#arch/i386/boot/Makefile
subdir- := compressed/
上面的赋值命令告诉Kbuild，当执行"make clean"时，要递归访问目录 compressed/。
为了支持在最终编译完成启动镜像后的架构清理工作，还有一可选的目标 archclean：
例子：
#arch/i386/Makefile
archclean:
$(Q)$(MAKE) $(clean)=arch/i386/boot
当"make clean"执行时，make会递归访问并清理 arch/i386/boot。在 arch/i386/boot
中的Makefile可以用来提示make进行下一步的递归操作。
注意1：arch/$(ARCH)/Makefile 不能使用"subdir-"，因为该Makefile被包含在顶层的
Makefile中，Kbuild是不会在此处进行操作的。
注意2："make clean" 会访问在 core-y，libs-y，drivers-y 和 net-y 列出的所有目
录。
=== 6 架构Makefile
在递归访问目录之前，顶层Makefile要完成设置环境变量以及递归访问的准备工作。顶
层Makefile包含的公共部分，而 arch/$(ARCH)/Makefile 包含着针对某一特定架构的
配置信息。
所以，要在 arch/$(ARCH)/Makefile 中设置一部分变量，并定义一些目标。
Kbuild执行的几个步骤(大致)：
1) 根据内核配置生成文件 .config
2) 将内核的版本号存储在 include/linux/version.h
3) 生成指向 include/asm-$(ARCH) 的符号链接
4) 更新所有编译所需的文件：
-附加的文件由 arch/$(ARCH)/Makefile 指定。
5) 递归向下访问所有在下列变量中列出的目录： init-* core* drivers-* net-*
libs-*，并编译生成目标文件。
-这些变量的值可以在 arch/$(ARCH)/Makefile 中扩充。
6) 联接所有的目标文件，在源代码树顶层目录中生成 vmlinux。最先联接是在 head-y中
列出的文件，该变量由 arch/$(ARCH)/Makefile 赋值。
7) 最后完成具体架构的特殊要求，并生成最终的启动镜像。
-包含生成启动指令
-准备 initrd 镜像或类似文件
--- 6.1 调整针对某一具体架构生成的镜像
LDFLAGS 一般是 $(LD) 选项
该选项在每次调用联接器时都会用到。
一般情况下，只用来指明模拟器。
例子：
#arch/s390/Makefile
LDFLAGS := -m elf_s390
注意：EXTRA_LDFLAGS 和 LDFLAGS_$@ 可用来进一步自定义选项。请看第七章。
LDFLAGS_MODULE 联接模块时的联接器的选项
LDFLAGS_MODULE 所设置的选项将在联接器在联接模块文件 .ko 时使用。
默认值为 "-r"，指定输出文件是可重定位的。
LDFLAGS_vmlinux 联接vmlinux时的选项
LDFLAGS_vmlinux用来传递联接vmlinux时的联接器的选项。
LDFLAGS_vmlinux需 LDFLAGS_$@ 支持。
例子：
#arch/i386/Makefile
LDFLAGS_vmlinux := -e stext
OBJCOPYFLAGS objcopy 选项
当用 $(call if_changed,objcopy) 来转换(translate)一个.o文件时，该选项
就会被使用。
$(call if_changed,objcopy) 经常被用来为vmlinux生成原始的二进制代码。
例子：
#arch/s390/Makefile
OBJCOPYFLAGS := -O binary
＃arch/s390/boot/Makefile
$(obj)/image: vmlinux FORCE
$(call if_changed,objcopy)
在此例中，二进制文件 $(obj)/image 是 vmlinux 的一个二进制版本。
$(call if_chagned,xxx)的用法稍后描述。
AFLAGS $(AS) 汇编编译器选项
默认值在顶层Makefile
扩充或修改在各具体架构的Makefile
例子：
#arch/sparc64/Makefile
AFLAGS += -m64 -mcpu=ultrasparc
CFLAGS $(CC) 编译器选项
默认值在顶层Makefile
扩充或修改在各具体架构的Makefile。
一般，CFLAGS要根据内核配置设置。
例子：
#arch/i386/Makefile
cflags-$(CONFIG_M386) += -march=i386
CFLAGS += $(cflags-y)
许多架构Makefile都通过调用所要使用的C编译器，动态的检查其所支持的选
项：
#arch/i386/Makefile
...
cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686)
...
# Disable unit-at-a-time mode ...
CFLAGS += $(call cc-option,-fno-unit-at-a-time)
...
第一个例子利用了一个配置选项，当其为'y'时，扩展。
CFLAGS_KERNEL ：
#arch/i386/Makefile
...
cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686)
...
# Disable unit-at-a-time mode ...
CFLAGS += $(call cc-option,-fno-unit-at-a-time)
...
第一个例子利用了一个配置选项，当其为'y'时，扩展。
CFLAGS_KERNEL 编译进内核时，$(CC) 所用的选项
$(CFLAGS_KERNEL) 包含了用于编译常驻内核代码的附加编译器选项。
CFLAGS_MODULE 编译成模块时，$(CC)所用的选项
$(CFLAGS_MODULE) 包含了用于编译可装载模块的附加编译器选项。
--- 6.2 将所需文件加到 archprepare 中：
archprepare规则在递归访问子目录之前，列出编译目标文件所需文件。
一般情况下，这是一个包含汇编常量的头文件。(assembler constants)
例子：
#arch/arm/Makefile
archprepare: maketools
此例中，目标文件 maketools 将在递归访问子目录之前编译。
在TODO一章可以看到，Kbuild是如何支持生成分支头文件的。
(offset header files)
--- 6.3 递归下向时要访问的目录列表
如何生成 vmlinux，是由架构makefile和顶层Makefile一起来定义的。注意,
架构Makefile是不会定义与模块相关的内容的，所有构建模块的定义是与架构
无关的。
head-y,init-y,core-y,libs-y,drivers-y,net-y
$(head-y) 列出了最先被联接进 vmlinux 的目标文件。
$(libs-y) 列出了生成的所有 lib.a 所在的目录。
其余所列的目录，是 built-in.o 所在的目录。
$(init-y) 在 $(head-y) 之后所要使用的文件。
然后，剩下的步骤如下：
$(core-y),$(libs-y),$(drivers-y)和$(net-y)。
顶层makefile定义了通用的部分，arch/$(ARCH)/Makefile 添加了架构的特殊
要求。
例子：
#arch/sparc64/Makefile
core-y += arch/sparc64/kernel/
libs-y += arch/sparc64/prom/ arch/sparc64/lib/
drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/
--- 6.4 具体架构的启动镜像
一具体架构Makefile的具体目的就是，将生成并压缩 vmlinux 文件，写入启动
代码，并将其拷贝到正确的位置。这就包含了多种不同的安装命令。该具体目的
也无法在各个平台间进行标准化。
一般，附加的处理命令入在 arch/$(ARCH)/下的boot目录。
Kbuild并没有为构造boot所指定的目标提供任何更好的方法。所以，
arch/$(ARCH)/Makefile 将会调用 make 以手工构造 boot的目标文件。
比较好的方法是，在 arch/$(ARCH)/Makefile 中包含快捷方式，并在
arch/$(ARCH)/boot/Makefile 中使用全部路径。
例子：
#arch/i386/Makefile
boot := arch/i386/boot
bzImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
当在子目录中调用 make 时，推荐使用 "$(Q)$(MAKE) $(build)=<dir>" 。
并没有对架构特殊目标的命名规则，但用命令 "make help" 可以列出所有的
相关目标。
为了支持 "make help"，$(archhelp) 必须被定义。
例子：
#arch/i386/Makefile
define archhelp
echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
endef
当make 没带参数执行时，所遇到的第一个目标将被执行。在顶层，第一个目标
就是 all：。
每个架构Makefile都要默认构造一可启动的镜像文件。
在 "make help"中，默认目标就是被加亮的'*'。
添加一新的前提文件到 all：，就可以构造出一不同的vmlinux。
例子：
#arch/i386/Makefile
all: bzImage
当 make 没有参数时，bzImage将被构造。
--- 6.5 构造非Kbuild目标
extra-y
extra-y 列出了在当前目录下，所要创建的附加文件，不包含任何已包含在
obj-* 中的文件。
用 extra-y 列目标，主要是两个目的：
1) 可以使Kbuild检查命令行是否发生变化
- 使用 $(call if_changed,xxx) 的时候
2) 让Kbuild知道哪些文件要在 "make clean" 时删除
例子：
#arch/i386/kernel/Makefile
extra-y := head.o init_task.o
在此例子中，extra-y用来列出所有只编译，但不联接到 built-in.o的目标
文件。
--- 6.6 构建启动镜像的命令
Kbuild 提供了几个用在构建启动镜像时的宏。
if_changed
if_changed 为下列命令的基础。
使用方法：
target: source(s) FORCE
$(call if_changed,ld/objcopy/gzip)
当执行该规则时，就检查是否有文件需要更新，或者在上次调用以后，命令行
发生了改变。如果有选项发生了改变，后者会导致重新构造。
只有在 $(targets)列出的的目标文件，才能使用 if_changed，否则命令行的
检查会失败，并且目标总会被重建。
给 $(targets)的赋值没有前缀 $(obj)/ 。 if_changed 可用来联接自定义的
Kbuild命令，关于Kbuild自定义命令请看 6.7节。
注意：忘记 FORCE 是一种典型的错误。还有一种普遍的错误是，空格有的时候
是有意义的；比如。下面的命令就会错误(注意在逗号后面的那个多余的空格)：
target: source(s) FORCE
#WRONG!# $(call if_changed, ld/objcopy/gzip)
ld
联接目标。经常是使用LDFLAGS_$@来设置ld的特殊选项。
objcopy
拷贝二进制代码。一般是在 arch/$(ARCH)/Makefile 中使用 OBJCOPYFLAGS。
OBJCOPYFLAGS_$@ 可以用来设置附加选项。
gzip
压缩目标文件。尽可能的压缩目标文件。
例子：
#arch/i386/boot/Makefile
LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext
targets += setup setup.o bootsect bootsect.o
$(obj)/setup $(obj)/bootsect: %: %.o FORCE
$(call if_changed,ld)
在这个例子中，有两个可能的目标文件，分别要求不同的联接选项。定义联接
器的选项使用的是 LDFLAGS_$@ 语法，每个潜在的目标一个。
$(targets) 被分配给所有的潜在目标，因此知道目标是哪些，并且还会：
1) 检查命令行是否改变
2) 在 "make clean" 时，删除目标文件
前提部分中的 ": %: %.o" 部分使我们不必在列出文件 setup.o 和
bootsect.o 。
注意：一个普遍的错误是忘记了给 "target"赋值，导致在target中的文件总是
无缘无故的被重新编译。
--- 6.7 Kbuild自定义命令
当Kbuild的变量 KBUILD_VERBOSE 为0时，只会显示命令的简写。
如果要为自定义命令使用这一功能，需要设置2个变量：
quiet_cmd_<command> - 要显示的命令
cmd_<command> - 要执行的命令
例子：
#
quiet_cmd_image = BUILD $@
cmd_image = $(obj)/tools/build $(BUILDFLAGS) \
$(obj)/vmlinux.bin > $@
targets += bzImage
$(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE
$(call if_changed,image)
@echo 'Kernel: $@ is ready'
当用"make KBUILD_VERBOSE=0"更新 $(obj)/bzImage 目标时显示：
BUILD arch/i386/boot/bzImage
--- 6.8 联接器预处理脚本
当构造 vmlinux 镜像时，使用联接器脚本：
arch/$(ARCH)/kernel/vmlinux.lds。
该脚本是由在同一目录下的 vmlinux.lds.S 生成的。
Kbuild认识.lds文件，并包含由*.lds.S文件生成*.lds文件的规则。
例子：
#arch/i386/kernel/Makefile
always := vmlinux.lds
#Makefile
export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
$(always)的值是用来告诉Kbuild，构造目标 vmlinux.lds。
$(CPPFLAGS_vmlinux.lds)，Kbuild在构造目标vmlinux.lds时所用到的特殊
选项。
当构造 *.lds 目标时，Kbuild要用到下列变量：
CPPFLAGS : 在顶层目录中设置
EXTRA_CPPFLAGS : 可以在Kbuild Makefile中设置
CPPFLAGS_$(@F) : 目标特别选项
注意，此处的赋值用的完整的文件名。
针对*.lds文件的Kbuild构架还被用在许多具体架构的文件中。(***不通***)
=== 7 Kbuild 变量
顶层Makefile输出以下变量：
VERSION,PATCHLEVEL,SUBLEVEL,EXTRAVERSION
这些变量定义了当前内核的版本号。只有很少一部分Makefile会直接用到这些
变量；可使用 $(KERNELRELEASE)代替。
$(VERSION),$(PATCHLEVEL),和$(SUBLEVEL) 定义了最初使用的三个数字的版本
号，比如"2""4"和"0"。这三个值一般是数字。
$(EXTRAVERSION) 为了补丁定义了更小的版本号。一般是非数字的字符串，比如
"-pre4" ，或就空着。
KERNELRELEASE
$(KERNELRELEASE) 是一个字符串，类似"2.4.0-pre4"，用于安装目录的命名或
显示当前的版本号。一部分架构Makefile使用该变量。
ARCH
该变量定义了目标架构，比如"i386","arm" 或"sparc"。有些Kbuild Makefile
根据 $(ARCH) 决定编译哪些文件。
默认情况下，顶层Makefile将其设置为本机架构。如果是跨平台编译，用户可以
用下面的命令覆盖该值：
make ARCH=m68k ...
INSTALL_PATH
该变量为架构Makefile定义了安装内核镜像与 System.map 文件的目录。
主要用来指明架构特殊的安装路径。
INSTALL_MOD_PATH,MODLIB
$(INSTALL_MOD_PATH) 为了安装模块，给 $(MODLIB) 声明了前缀。该变量不能
在Makefile中定义，但可以由用户传给Makefile。
$(MODLIB) 具体的模块安装的路径。顶层Makefile将$(MODLIB)定义为
$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)。用户可以通过命令行
参数的形式将其覆盖。
INSTALL_MOD_STRIP
如果该变量有定义，模块在安装之前，会被剥出符号表。如果
INSTALL_MOD_STRIP 为 "1"，就使用默认选项 --strip-debug。否则，
INSTALL_MOD_STRIP 将作为命令 strip 的选项使用。
=== 8 Makefile语言
内核的Makefile使用的是GNU Make。该Makefile只使用GNU Make已注明的功能，并使用
了许多GNU 的扩展功能。
GNU Make支持基本的显示处理过程的函数。内核Makefile 使用了一种类似小说的方式
，显示"if"语句的构造、处理过程。
GNU Make 有2个赋值操作符，":="和"="。":="，将对右边的表达式求值，并将所求的值
赋给左边。"="更像是一个公式定义，只是将右边的值简单的赋值给左边，当左边的表达
式被使用时，才求值。
有时使用"="是正确的。但是，一般情况下，推荐使用":="。
=== 9 关于作者
第一版由 Michael Elizabeth Chastain,<mailto:mec@shout.net>
修改：kai Germaschewski <kai@tpl.ruhr-uni-bochum.de>
Sam Ravnborg <sam@ravnborg.org>
=== 10 TODO
- 描述Kbuild是如何用 _shipped 来支持 shipped 文件的。
- 生成分支头文件
- 在第7节加入更多的变量
Udev 研究
简介： 本文以通俗的方法阐述 udev 及相关术语的概念、udev 的配置文件和规则文件，然后以 Red Hat Enterprise Server 为平台演示一些管理设备文件和查询设备信息的实例。本文会使那些需要高效地、方便地管理 Linux 设备的用户受益匪浅，这些用户包括 Linux 最终用户、设备驱动开发人员、设备测试人员和系统管理员等等。
概述：
Linux 用户常常会很难鉴别同一类型的设备名，比如 eth0, eth1, sda, sdb 等等。通过观察这些设备的内核设备名称，用户通常能知道这些是什么类型的设备，但是不知道哪一个设备是他们想要的。例如，在一个充斥着本地磁盘和光纤磁盘的设备名清单 (/dev/sd*) 中，用户无法找到一个序列号为“35000c50000a7ef67”的磁盘。在这种情况下，udev 就能动态地在 /dev目录里产生自己想要的、标识性强的设备文件或者设备链接，以此帮助用户方便快捷地找到所需的设备文件。
udev 是 Linux2.6 内核里的一个功能，它替代了原来的 devfs，成为当前 Linux 默认的设备管理工具。udev 以守护进程的形式运行，通过侦听内核发出来的 uevent 来管理 /dev目录下的设备文件。不像之前的设备管理工具，udev 在用户空间 (user space) 运行，而不在内核空间 (kernel space) 运行。
我们都知道，所有的设备在 Linux 里都是以设备文件的形式存在。在早期的 Linux 版本中，/dev目录包含了所有可能出现的设备的设备文件。很难想象 Linux 用户如何在这些大量的设备文件中找到匹配条件的设备文件。现在 udev 只为那些连接到 Linux 操作系统的设备产生设备文件。并且 udev 能通过定义一个 udev 规则 (rule) 来产生匹配设备属性的设备文件，这些设备属性可以是内核设备名称、总线路径、厂商名称、型号、序列号或者磁盘大小等等。
- 动态管理：当设备添加 / 删除时，udev 的守护进程侦听来自内核的 uevent，以此添加或者删除
/dev下的设备文件，所以 udev 只为已经连接的设备产生设备文件，而不会在/dev下产生大量虚无的设备文件。 - 自定义命名规则：通过 Linux 默认的规则文件，udev 在 /dev/ 里为所有的设备定义了内核设备名称，比如
/dev/sda、/dev/hda、/dev/fd等等。由于 udev 是在用户空间 (user space) 运行，Linux 用户可以通过自定义的规则文件，灵活地产生标识性强的设备文件名，比如/dev/boot_disk、/dev/root_disk、/dev/color_printer等等。 - 设定设备的权限和所有者 / 组：udev 可以按一定的条件来设置设备文件的权限和设备文件所有者 / 组。在不同的 udev 版本中，实现的方法不同，在“如何配置和使用 udev”中会详解。
下面的流程图显示 udev 添加 / 删除设备文件的过程。
- 设备文件：由于本文以较通俗的方式讲解 udev，所以设备文件是泛指在
/dev/下，可被应用程序用来和设备驱动交互的文件。而不会特别地区分设备文件、设备节点或者设备特殊文件。 - devfs：devfs是 Linux 早期的设备管理工具，已经被 udev 取代。
- sysfs：sysfs是 Linux 2.6 内核里的一个虚拟文件系统
(/sys)。它把设备和驱动的信息从内核的设备模块导出到用户空间 (userspace)。从该文件系统中，Linux 用户可以获取很多设备的属性。 - devpath：本文的 devpath是指一个设备在 sysfs文件系统
(/sys)下的相对路径，该路径包含了该设备的属性文件。udev 里的多数命令都是针对 devpath操作的。例如：sda的 devpath是/block/sda，sda2 的 devpath是/block/sda/sda2。 - 内核设备名称：设备在 sysfs里的名称，是 udev 默认使用的设备文件名。
下面会以 RHEL4.8 和 RHEL5.3 为平台，分别描述 udev 的配置和使用：
从 Fedora3 和 Red Hat Enterprise4 开始，udev 就是默认的设备管理工具，无需另外下载安装。
清单 1. 检查 udev 在 RHEL4.8 里的版本和运行情况
[root@HOST_RHEL4 dev]# rpm -qa |grep -i udev udev-039-10.29.el4 [root@HOST_RHEL4 ~]# uname -r 2.6.9-89.ELsmp [root@HOST_RHEL4 ~]# ps -ef |grep udev root 21826 1 0 Dec09 ? 00:00:00 udevd |
清单 2. 检查 udev 在 RHEL5.3 里的版本和运行情况
[root@HOST_RHEL5 ~]# rpm -qa |grep -i udev udev-095-14.19.el5 [root@HOST_RHEL5 sysconfig]# uname -r 2.6.18-128.el5 [root@HOST_RHEL5 sysconfig]# ps -ef|grep udev root 5466 1 0 18:32 ? 00:00:00 /sbin/udevd -d |
如果 Linux 用户想更新 udev 包，可以从 http://www.kernel.org/pub/linux/utils/kernel/hotplug/下载并安装。
udev 的配置文件 (/etc/udev/udev.conf)
[root@HOST_RHEL4 dev]# cat /etc/udev/udev.conf # udev.conf # The main config file for udev # # This file can be used to override some of udev's default values # for where it looks for files, and where it places device nodes. # # WARNING: changing any value, can cause serious system breakage! # # udev_root - where in the filesystem to place the device nodes udev_root="/dev/" # udev_db - The name and location of the udev database. udev_db="/dev/.udev.tdb" # udev_rules - The name and location of the udev rules file udev_rules="/etc/udev/rules.d/" # udev_permissions - The name and location of the udev permission file udev_permissions="/etc/udev/permissions.d/" # default_mode - set the default mode for all nodes that have no # explicit match in the permissions file default_mode="0600" # default_owner - set the default owner for all nodes that have no # explicit match in the permissions file default_owner="root" # default_group - set the default group for all nodes that have no # explicit match in the permissions file default_group="root" # udev_log - set to "yes" if you want logging, else "no" udev_log="no" |
Linux 用户可以通过该文件设置以下参数：
- udev_root：udev 产生的设备所存放的目录，默认值是
/dev/。建议不要修改该参数，因为很多应用程序默认会从该目录调用设备文件。 - udev_db：udev 信息存放的数据库或者所在目录，默认值是
/dev/.udev.tdb。 - udev_rules：udev 规则文件的名字或者所在目录，默认值是
/etc/udev/rules.d/。 - udev_permissions：udev 权限文件的名字或者所在目录，默认值是
/etc/udev/permissions.d/。 - default_mode/ default_owner/ default_group：如果设备文件的权限没有在权限文件里指定，就使用该参数作为默认权限，默认值分别是：
0600/root/root。 - udev_log：是否需要 syslog记录 udev 日志的开关，默认值是 no。
[root@HOST_RHEL5 ~]# cat /etc/udev/udev.conf # udev.conf # The initial syslog(3) priority: "err", "info", "debug" or its # numerical equivalent. For runtime debugging, the daemons internal # state can be changed with: "udevcontrol log_priority= |
udev_log：syslog记录日志的级别，默认值是 err。如果改为 info 或者 debug 的话，会有冗长的 udev 日志被记录下来。
实际上在 RHEL5.3 里，除了配置文件里列出的参数 udev_log外，Linux 用户还可以修改参数 udev_root和 udev_rules( 请参考上面的“RHEL4.8 的 udev 配置文件”)，只不过这 2 个参数是不建议修改的，所以没显示在 udev.conf 里。
可见该版本的 udev.conf 改动不小：syslog默认会记录 udev 的日志，Linux 用户只能修改日志的级别 (err、info、degub 等 )；设备的权限不能在 udev.conf 里设定，而是要在规则文件 (*.rules) 里设定。
在 RHEL4.8 的 udev，设备的权限是通过权限文件来设置。
[root@HOST_RHEL4 ~]# cat /etc/udev/permissions.d/50-udev.permissions …… # disk devices hd*:root:disk:0660 sd*:root:disk:0660 dasd*:root:disk:0660 ataraid*:root:disk:0660 loop*:root:disk:0660 md*:root:disk:0660 ide/*/*/*/*/*:root:disk:0660 discs/*/*:root:disk:0660 loop/*:root:disk:0660 md/*:root:disk:0660 # tape devices ht*:root:disk:0660 nht*:root:disk:0660 pt[0-9]*:root:disk:0660 npt*:root:disk:0660 st*:root:disk:0660 nst*:root:disk:0660 …… |
RHEL4.8 里 udev 的权限文件会为所有常用的设备设定权限和 ownership，如果有设备没有被权限文件设置权限，udev 就按照 udev.conf 里的默认权限值为这些设备设置权限。由于篇幅的限制，上图只显示了 udev 权限文件的一部分，该部分设 置了所有可能连接上的磁盘设备和磁带设备的权限和 ownership。
而在 RHEL5.3 的 udev，已经没有权限文件，所有的权限都是通过规则文件 (*.rules)来设置，在下面的规则文件配置过程会介绍到。
规则文件是 udev 里最重要的部分，默认是存放在 /etc/udev/rules.d/下。所有的规则文件必须以“.rules”为后缀名。RHEL 有默认的规则文件，这些默认规则文件不仅为设备产生内核设备名称，还会产生标识性强的符号链接。例如：
[root@HOST_RHEL5 ~]# ls /dev/disk/by-uuid/ 16afe28a-9da0-482d-93e8-1a9474e7245c |
但这些链接名较长，不易调用，所以通常需要自定义规则文件，以此产生易用且标识性强的设备文件或符号链接。
此外，一些应用程序也会在 /dev/下产生一些方便调用的符号链接。例如规则 40-multipath.rules 为磁盘产生下面的符号链接：
[root@ HOST_RHEL5 ~]# ls /dev/mpath/* /dev/mpath/mpath0 /dev/mpath/mpath0p1 /dev/mpath/mpath0p2 |
udev 按照规则文件名的字母顺序来查询全部规则文件，然后为匹配规则的设备管理其设备文件或文件链接。虽然 udev 不会因为一个设备匹配了一条规则而停止解析后面的规则文件，但是解析的顺序仍然很重要。通常情况下，建议让自己想要的规则文件最先被解析。比如，创建一个名为 /etc/udev/rules.d/10-myrule.rules的文件，并把你的规则写入该文件，这样 udev 就会在解析系统默认的规则文件之前解析到你的文件。
RHEL5.3 的 udev 规则文件比 RHEL4.8 里的更完善。受篇幅的限制，同时也为了不让大家混淆，本文将不对 RHEL4.8 里的规则文件进行详解，下面关于规则文件的配置和实例都是在 RHEL5.3 上进行的。如果大家需要配置 RHEL4 的 udev 规则文件，可以先参照下面 RHEL5.3 的配置过程，然后查询 RHEL4 里的用户手册 (man udev) 后进行配置。
在规则文件里，除了以“#”开头的行（注释），所有的非空行都被视为一条规则，但是一条规则不能扩展到多行。规则都是由多个 键值对（key-value pairs）组成，并由逗号隔开，键值对可以分为 条件匹配键值对( 以下简称“匹配键 ”) 和 赋值键值对( 以下简称“赋值键 ”)，一条规则可以有多条匹配键和多条赋值键。匹配键是匹配一个设备属性的所有条件，当一个设备的属性匹配了该规则里所有的匹配键，就认为这条规则生效，然后按照赋值键的内容，执行该规则的赋值。下面是一个简单的规则：
KERNEL=="sda", NAME="my_root_disk", MODE="0660" |
KERNEL 是匹配键，NAME 和 MODE 是赋值键。这条规则的意思是：如果有一个设备的内核设备名称为 sda，则该条件生效，执行后面的赋值：在 /dev下产生一个名为 my_root_disk的设备文件，并把设备文件的权限设为 0660。
通过这条简单的规则，大家应该对 udev 规则有直观的了解。但可能会产生疑惑，为什么 KERNEL 是匹配键，而 NAME 和 MODE 是赋值键呢？这由中间的操作符 (operator) 决定。
仅当操作符是“==”或者“!=”时，其为匹配键；若为其他操作符时，都是赋值键。
- RHEL5.3 里 udev 规则的所有操作符：
“==”：比较键、值，若等于，则该条件满足；
“!=”： 比较键、值，若不等于，则该条件满足；
“=”： 对一个键赋值；
“+=”：为一个表示多个条目的键赋值。
“:=”：对一个键赋值，并拒绝之后所有对该键的改动。目的是防止后面的规则文件对该键赋值。
- RHEL5.3 里 udev 规则的匹配键
ACTION： 事件 (uevent) 的行为，例如：add( 添加设备 )、remove( 删除设备 )。
KERNEL： 内核设备名称，例如：sda, cdrom。
DEVPATH：设备的 devpath 路径。
SUBSYSTEM： 设备的子系统名称，例如：sda 的子系统为 block。
BUS： 设备在 devpath 里的总线名称，例如：usb。
DRIVER： 设备在 devpath 里的设备驱动名称，例如：ide-cdrom。
ID： 设备在 devpath 里的识别号。
SYSFS{filename}： 设备的 devpath 路径下，设备的属性文件“filename”里的内容。
例如：SYSFS{model}==“ST936701SS”表示：如果设备的型号为 ST936701SS，则该设备匹配该 匹配键。
在一条规则中，可以设定最多五条 SYSFS 的 匹配键。
ENV{key}： 环境变量。在一条规则中，可以设定最多五条环境变量的 匹配键。
PROGRAM：调用外部命令。
RESULT： 外部命令 PROGRAM 的返回结果。例如：
PROGRAM=="/lib/udev/scsi_id -g -s $devpath", RESULT=="35000c50000a7ef67"
调用外部命令
/lib/udev/scsi_id查询设备的 SCSI ID，如果返回结果为 35000c50000a7ef67，则该设备匹配该 匹配键。 - RHEL5.3 里 udev 的重要赋值键
NAME：在
/dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效，之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值，udev 将使用内核设备名称来产生设备文件。SYMLINK：为
/dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件，所以为了不覆盖系统默认的 udev 规则所产生的文件，推荐使用符号链接。OWNER, GROUP, MODE：为设备设定权限。
ENV{key}：导入一个环境变量。
- RHEL5.3 里 udev 的值和可调用的替换操作符
在键值对中的键和操作符都介绍完了，最后是值 (value)。Linux 用户可以随意地定制 udev 规则文件的值。例如：
my_root_disk, my_printer。同时也可以引用下面的替换操作符：$kernel, %k：设备的内核设备名称，例如：sda、cdrom。
$number, %n：设备的内核号码，例如：sda3 的内核号码是 3。
$devpath, %p：设备的 devpath路径。
$id, %b：设备在 devpath里的 ID 号。
$sysfs{file}, %s{file}：设备的 sysfs里 file 的内容。其实就是设备的属性值。
例如：$sysfs{size} 表示该设备 ( 磁盘 ) 的大小。$env{key}, %E{key}：一个环境变量的值。
$major, %M：设备的 major 号。
$minor %m：设备的 minor 号。
$result, %c：PROGRAM 返回的结果。
$parent, %P：父设备的设备文件名。
$root, %r：udev_root的值，默认是
/dev/。$tempnode, %N：临时设备名。
%%：符号 % 本身。
$$：符号 $ 本身。
清单 7. 说明替换操作符的规则例子
KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", \ RESULT=="35000c50000a7ef67", SYMLINK="%k_%c"
该规则的执行：如果有一个内核设备名称以 sd 开头，且 SCSI ID 为
35000c50000a7ef67，则为设备文件产生一个符号链接“sda_35000c50000a7ef67”.
如何查找设备的信息 ( 属性 ) 来制定 udev 规则：
当我们为指定的设备设定规则时，首先需要知道该设备的属性，比如设备的序列号、磁盘大小、厂商 ID、设备路径等等。通常我们可以通过以下的方法获得：
- 查询sysfs文件系统：
前面介绍过，sysfs 里包含了很多设备和驱动的信息。
例如：设备 sda 的 SYSFS{size} 可以通过
cat /sys/block/sda/size得到；SYSFS{model} 信息可以通过cat /sys/block/sda/device/model得到。 - udevinfo命令：
udevinfo 可以查询 udev 数据库里的设备信息。例如：用 udevinfo 查询设备 sda 的 model 和 size 信息：
清单 8. 通过 udevinfo 查询设备属性的例子
[root@HOST_RHEL5 rules.d]# udevinfo -a -p /block/sda | egrep "model|size" SYSFS{size}=="71096640" SYSFS{model}=="ST936701SS "
- 其他外部命令：
清单 9. 通过 scsi_id 查询磁盘的 SCSI_ID 的例子
[root@HOST_RHEL5 ~]# scsi_id -g -s /block/sda 35000c50000a7ef67
udev 的简单规则：
SUBSYSTEM=="net", SYSFS{address}=="AA:BB:CC:DD:EE:FF", NAME="public_NIC" |
该规则表示：如果存在设备的子系统为 net，并且地址 (MAC address) 为“AA:BB:CC:DD:EE:FF”，为该设备产生一个名为 public_NIC 的设备文件。
SUBSYSTEM=="block", SYSFS{size}=="71096640", SYMLINK ="my_disk" |
该规则表示：如果存在设备的子系统为 block，并且大小为 71096640(block)，则为该设备的设备文件名产生一个名为 my_disk 的符号链接。
清单 12. 通过外部命令为指定序列号的磁盘产生设备文件的规则
KERNEL=="sd*[0-9]", PROGRAM=="/lib/udev/scsi_id -g -s %p", \ RESULT=="35000c50000a7ef67", NAME +="root_disk%n" |
该规则表示：如果存在设备的内核设备名称是以 sd 开头 ( 磁盘设备 )，以数字结尾 ( 磁盘分区 )，并且通过外部命令查询该设备的 SCSI_ID 号为“35000c50000a7ef67”，则产生一个以 root_disk 开头，内核号码结尾的设备文件，并替换原来的设备文件（如果存在的话）。例如：产生设备名 /dev/root_disk2，替换原来的设备名 /dev/sda2。
运用这条规则，可以在 /etc/fstab里保持系统分区名称的一致性，而不会受驱动加载顺序或者磁盘标签被破坏的影响，导致操作系统启动时找不到系统分区。
其他常用的 udev 命令：
- udevtest:
udevtest会针对一个设备，在不需要 uevent 触发的情况下模拟一次udev的运行，并输出查询规则文件的过程、所执行的行为、规则文件的执行结果。通常使用udevtest来调试规则文件。以下是一个针对设备 sda 的udevtest例子。由于udevtest是扫描所有的规则文件 ( 包括系统自带的规则文件 )，所以会产生冗长的输出。为了让读者清楚地了解udevtest，本例只在规则目录里保留一条规则：
清单 13. 为 udevtest 保留的规则
KERNEL=="sd*", PROGRAM="/lib/udev/scsi_id -g -s %p", RESULT=="35000c50000a7ef67", \ NAME="root_disk%n", SYMLINK="symlink_root_disk%n"
清单 14. udevtest 的执行过程
[root@HOST_RHEL5 rules.d]# udevtest /block/sda main: looking at device '/block/sda' from subsystem 'block' run_program: '/lib/udev/scsi_id -g -s /block/sda' run_program: '/lib/udev/scsi_id' (stdout) '35000c50000a7ef67' run_program: '/lib/udev/scsi_id' returned with status 0 udev_rules_get_name: reset symlink list udev_rules_get_name: add symlink 'symlink_root_disk' udev_rules_get_name: rule applied, 'sda' becomes 'root_disk' udev_device_event: device '/block/sda' already in database, \ validate currently present symlinks udev_node_add: creating device node '/dev/root_disk', major = '8', \ minor = '0', mode = '0660', uid = '0', gid = '0' udev_node_add: creating symlink '/dev/symlink_root_disk' to 'root_disk'
可以看出，
udevtest对 sda 执行了外部命令scsi_id, 得到的 stdout 和规则文件里的 RESULT 匹配，所以该规则匹配。然后 ( 模拟 ) 产生设备文件/dev/root_disk和符号链接/dev/symlink_root_disk，并为其设定权限。 - start_udev:
start_dev命令重启udev守护进程，并对所有的设备重新查询规则目录下所有的规则文件，然后执行所匹配的规则里的行为。通常使用该命令让新的规则文件立即生效：
清单 15. start_udev 的执行过程
[root@HOST_RHEL5 rules.d]# start_udev Starting udev: [ OK ]
start_udev一般没有标准输出，所有的 udev 相关信息都按照配置文件 (udev.conf)的参数设置，由 syslog记录。
回页首
udev 是高效的设备管理工具，其最大的优势是动态管理设备和自定义设备的命名规则，因此替代 devfs 成为 Linux 默认的设备管理工具。通过阅读本文，Linux 用户能够了解到 udev 的工作原理和流程，灵活地运用 udev 规则文件，从而方便地管理 Linux 设备文件。
跟我一起写udev规则
udev面向2.6以上的linux内核在用户空间提供动态的/dev下固定设备命名方案. 之前的/dev实现: devfs现在已被废弃, udev成为继任者. udev vs devfs是一个敏感的谈话内容,在进行比较之前你应该读一下这个文档(http://kernel.org/pub/linux/utils /kernel/hotplug/udev_vs_devfs).
几年间你为之使用udev规则的设备发生改变了,如同规则自身的弹性一样. 在现代系统中udev为系统外的类型设备提供了固定的命名方法, 避免了为这些设备提供定制规则. 但是一些用户仍然需要额外的定制级别.
本文档假设你已经安装了udev并使用缺省配置运行ok. 这通常通过你的linux发行版做到的.
语义: devfs, sysfs, nodes等
在典型的基于linux的系统中,/dev目录用来存储文件一样的设备节点, 它们指向系统中特定的设备. 每一个节点指向系统的一部分(一个设备), 可能存在也可能不存在. 用户空间应用程序可以使用这些设备节点跟系统硬件打交道,例如, X服务器"监听"/dev/input/mice来根据用户的鼠标移动来移动可视鼠标指针.
原来的/dev目录仅仅在设备可能在系统中出现时产生,因此/dev目录一般非常大. 随之而来的devfs提供了一种易于管理的途径(注意它仅仅在硬件插入到系统中时产生/dev)以及其他功能,但系统会出现无法容易修复的问题.
udev是一种新的管理/dev目录的方法,它的设计清除了以前的/dev实现的一些问题并提供了鲁棒的路径向后兼容. 为了创建并命名系统中相应的/dev设备结点,udev需要依赖于根据用户提供的规则从sysfs中得到的匹配信息. 本文着重规则书写的过程,udev相关的任务由用户自己完成.
sysfs是2.6内核中一个新的文件系统, 它由内核管理,并导出当前系统中插入的设备基本信息. udev可使用这些信息创建对应的硬件设备结点. sysfs挂载在/sys下而且是可浏览的. 你可能很希望在使用udev之前刺探下存储在那儿的有关文件. 本文中我将交替使用/sys和sysfs术语.
为什么？
udev规则具有弹性非常强大，这里是一些你使用规则可以达到的结果：
1. 重命名设备节点的缺省名字为其他名字
2. 通过创建符号链接到缺省设备节点来提供一个可选的固定的设备节点名字
3. 基于程序的输出命名设备节点
4. 改变设备节点的权限和所有权
5. 但设备节点被创建或删除时(通常是添加设备或拔出设备时)执行一个脚本
6. 重命名网络接口
当存在的特定设备没有设备节点时,这不是书写规则的工作范围. 即使没有匹配的规则,udev也会利用内核提供的缺省名字来创建设备节点.
拥有固定命名设备节点有很多好处. 假设你有两个USB存储设备:一个数码相机,一个是USB闪存盘. 这些设备通过被赋予/dev/sda和/dev/sdb设备节点,准确的赋值取决于它们连接到系统的顺序. 这可能为一些用户造成麻烦,如果每个设备每次都可以固定命名,比如/dev/camera和/dev/flashdisk,用户就会获益.
内置固定命名方法
udev为系统外的一些设备类型提供了固定命名,这是一个很有用的特征,在某些情况下意味着你不用书写任何规则.
udev为存储设备在/dev/disk目录下提供了系统外命名方法. 要查看它为你的存储硬件创建的固定命名,你可以使用下列命名:
#ls -lR /dev/disk
所有存储类型都可以这么用. 例如udev为我的根分区创建了固定命名链接:/dev/disk/by-id/scsi-SATA_ST3120827AS_4MS1NDXZ- part3. 但我插入我的USB闪存盘udev就会创建另外一个固定命名节点:/dev/disk/by-id/usb- Prolific_Technology_Inc._USB_Mass_Storage_Device-part1.
规则书写
规则文件和语义
为决定如何命名设备以及执行什么另外动作,udev会读取一系列规则文件. 这些文件保存在/etc/udev/rules.d目录下并且都必须有.rules后缀名.
缺省udev规则存储在/etc/udev/rules.d/50-udev.rules里面. 你可能发现整个文件很有意思, 它包含了少量例子,一些缺省规则提供了devfs风格的/dev布局, 但是你不应该直接在这个文件里面书写规则.
/etc/udev/rules.d/下面的文件通过lexical顺序解析,在某些情况下规则的解析顺序很重要. 通常来说你希望你的规则可以在缺省规则之前解析, 所以我建议你创建一个文件/etc/udev/rules.d/10-local.rules并把自己的所有规则写到这里面去.
在一个规则文件中, 以"#"开头的行被认为是注释. 每一个非空的行都是一条规则. 规则不能跨越多行.
一个设备可以被多条规则匹配到, 这有着很实用的优点, 例如, 我们可以写两个匹配同一个设备的规则, 每一个规则为设备提供了它自己的可选命名. 即使分开在不同的文件种, 两个可选命名也都会被创建, 要明白udev在找到一个匹配规则后不会停止处理其他规则, 它仍然会继续查找并尝试应用已知的每条规则, 这很重要.
规则语法
每条规则通过一系列键值对创建,这些键值对通过逗号分隔. 匹配键是用来识别要应用规则的设备的条件, 但规则中对应设备的所有匹配键被处理后,就会应用规则并且赋值键的行为也会触发. 每条规则应该包含至少一个匹配键和至少一个赋值键.
这是用来阐述上面内容的一个例子规则:
KERNEL=="hdb",NAME="my_spare_disk"
上述规则包含一个匹配键(KERNEL)以及一个赋值键(NAME). 这些键和它们的属性的语义将在稍后具体说明. 注意到匹配键通过连等号(==)与它的值联系起来, 赋值键通过等号(=)与它的值关联.
注意udev不支持任何形式的行连接符, 不要在你的规则种插入任何断行符,这将会导致udev把你的一条规则看做是多条规则但不会按预料工作.
基本规则
udev提供一些用来书写精确匹配规则的匹配键, 其中一些常用键将在下面介绍, 其他将在文档的后面说明. 要得到完整列表可以查看udev的手册页.
KERNEL - 为设备匹配的内核名字
SUBSYSTEM - 匹配设备的子系统
DRIVER - 匹配支持设备的驱动名称
在你使用一系列匹配键来准确匹配设备后,udev通过赋值键为接下来发生的事给你提供更好的控制. 你可以查看udev的手册页查看完整的赋值键列表. 最基本的赋值键在下面说明, 其他的将在文档结束时说明.
NAME - 设备节点应该使用的名字
SYMLINK - 一个设备节点可选名字的符号链接列表
正如之前所说,udev会为设备创建一个真正的设备节点. 如果你希望为设备节点提供可选名字,你得通过SYMLINK使用符号链接功能, 实际上是维护一个符号链接列表,这些符号链接都会指向真实的设备节点. 为了维护这些链接我们介绍一个新的附加操作符: +=. 你可以在一个规则中附加多个符号链接到列表中,每个链接通过空格分开.
KERNEL=="hdb", NAME="my_spare_disk"
上面规则意思是:匹配一个设备命名为hdb的设备,把它重新命名为my_spare_disk. 设备节点出现在/dev/my_spare_disk.
KERNEL=="hdb", DRIVER=="ide-disk", SYMLINK+="sparedisk"
上面规则意思是：匹配一个内核命名为hdb以及驱动为ide-disk的设备，命名设备节点为缺省名字并创建一个指向它的sparedisk符号链接。注意到我们没有指明设备节点名字，于是udev使用缺省名字。为了保留标准/dev布局,你自己的规则通常没有NAME但会创建一些SYMLINK并/或执行其他赋值操作.
KERNEL=="hdc", SYMLINK+="cdrom cdrom0"
上面规则很可能就是你要写的典型规则。 它在/dev/cdrom和/dev/cdrom0创建了两个符号链接,都指向/dev/hdc. 再一次地,没有NAME赋值键,所以使用缺省的内核名字(hdc).
匹配sysfs属性
到目前为止介绍的匹配键仅仅提供了有限的匹配能力. 实际上我们需要更加优良的控制:我们想基于设备的高级属性来识别设备, 如供应商编码, 产品编号, 序列号, 存储能力, 分区数等等.
一些驱动导出这些信息到sysfs, udev允许我们使用ATTR键通过稍捎不同的语法来合并sysfs匹配到自己的规则中.
这里有一个匹配sysfs中单个属性例子. 更多细节将在稍后的帮助你基于sysfs属性书写规则的文档中提供.
SUBSYSTEM=="block", ATTR{size}=="234441648", SYMLINK+="my_disk"
设备级联
linux内核实际上以树状结构展示设备, 这个信息通过sysfs显露出来,在书写规则时这非常有用. 例如我的硬盘设备的展示是一个SCSI磁盘设备的孩子, 这个SCSI磁盘设备又是一个ATA控制器设备的孩子, 该控制器又是PCI总线设备的孩子. 你很有可能发现你需要从一个讨论中的设备的双亲那里引用信息, 比如我的硬盘设备的序列号在设备级别并不暴露出来, 而是在SCSI磁盘级别通过它的直接双亲展现。
目前介绍的四个主要匹配键(KERNEL/SUBSYSTEM/DRIVER/ATTR)仅仅跟对应设备的值匹配, 并不跟双亲设备的值匹配. udev提供了在树中向上查找的匹配键变量:
KERNELS - 为设备匹配的内核名字,或任何双亲设备中的内核名
SUBSYSTEMS - 匹配设备的子系统名,或任何双亲设备中的子系统名
DRIVERS - 匹配支持设备的驱动名,或任何支持双亲设备的驱动名
ATTRS - 匹配设备的sysfs属性,或任何双亲设备的sysfs属性
由于在心里要考虑到级联结构,你可能感觉到规则书写变的有点复杂了. 歇一会吧,有工具可以帮助我们的,稍微献上.
字符串替换
但写的规则潜在的要处理多个相似的设备时, udev的printf-like string substitution operators就非常有用了. 你可以在你的规则里面的任何赋值里面包含这些操作符, udev在它们执行时会计算.
最常用的操作符是%k和%n. %k计算设备的内核名, 例如设备的"sda3"将(缺省)出现在/dev/sda3. %n计算设备(存储设备的分区号)的内核号码, 例如"3"将被换成"/dev/sda3".
udev也提供了一些高级功能替换操作符. 在读完本文剩下内容后可以查询udev的手册页. 以上例子中的操作符也有一个可选的语法 - $kernel和$number. 因此如果你希望在规则中匹配字符%, 你必需写成%%, 如果你希望匹配字符$, 你必须写成$$.
为阐述下字符串替换的概念,我们来展示几个例子:
KERNEL=="mice", NAME="input/%k"
KERNEL=="loop0", NAME="loop/%n", SYMLINK+="%k"
第一条规则确保鼠标设备节点一定出现在/dev/input目录下(缺省是在/dev/mice下面). 第二条规则确保名字为loop0的设备节点在/dev/loop/0创建,也会照常创建一个符号链接/dev/loop0.
上面规则的使用都比较可疑,因为他们都可以通过不使用任何替换操作符来重写. 这些替换的真正威力将会在下一节显现.
字符串匹配
不仅有字符串精确匹配, udev也允许你使用shell风格的模式匹配. 支持的3种模式为:
* - 匹配任何字符, 匹配0次或多次
? - 匹配任何字符,但只匹配一次.
[] - 匹配任何单个字符, 这些字符在方括号里面指定, 范围是受限的.
这里有一些例子, 注意字符串替换符的使用:
KERNEL=="fd[0-9]*", NAME="floppy/%n", SYMLINK+="%k"
KERNEL=="hiddev*", NAME="usb/%k"
第一条规则匹配所有软盘驱动并确保设备节点放置在/dev/floppy目录下, 也创建一个缺省名字的符号链接. 第二条规则确保hiddev设备节点放在/dev/usb目录下面.
从sysfs中查找信息
sysfs树
从sysfs中获取有意思信息的概念在之前的例子中已经触摸到了. 为了基于这些信息书写规则,你首先需要知道属性名和他们的当前值.
sysfs实际上是一个非常简单的结构,逻辑上以目录形式区分. 每一个目录包含一定量的文件(属性),这些文件往往都仅仅包含一个值. 也会有一些符号链接,它们把设备链到双亲那里, 级联结构已在上面说明了.
一些目录被引?
