搜索命令:find -name “confid” 搜索文件夹名称
grep “config” * -nwR 当前目录哪个文件出现了 config 字样 -n在第几行
配置结果:生成 .config
配置项:CONFIG_DM9000
在哪里出现(用grep命令查找):
c源码:CONFIG_DM9000 宏
makefile:drivers/net/Makefile
include/config/auto.conf
include/linux/autoconfig.h
make命令执行是自动生成include/linux/autoconfig.h 其中用#define CONFIG_DM9000 1 (体现不出 m y 的区别)
总结:配置内核生成.config
make uImage时 .config生成autoconfig.h(用于源代码)和auto.conf(被顶层makefile调用)。 make的时候makefile有(obj-$(CONFIG_DM9000) += dm9000.o)通过auto.cong有(CONFIG_DM9000=y);autoconfig.h中有(CONFIG_DM9000=1)
内核功能,结构分析,结合makefile kconfig分析: 分析Makefile:第一个文件,链接脚本
1 makefile的调用
linux/Documentation/kbuild/makefiles.txt对makefile讲解的很透彻有空要看看
make uImage时先执行顶层的makefile,其会调用arch/arm/Makefile(其中用uImage)
顶层Makefile:
include $(srctree)/arch/$(ARCH)/Makefile
-include include/linux/autoconf.h
-include include/config/auto.conf
include $(srctree)/arch/$(ARCH)/Makefile
zImage Image xipImage bootpImage uImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
2 vmlinux的组成
//vmlinux 是uImage的主要组成部分
vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
vmlinux-init := $(head-y) $(init-y)
head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
init-y := init/
init-y := $(patsubst %/, %/built-in.o, $(init-y))
init-y := $(patsubst %/, %/built-in.o, $(init-y))
vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
core-y := usr/
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
core-y := $(patsubst %/, %/built-in.o, $(core-y))
libs-y := lib/
libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y))
libs-y := $(libs-y1) $(libs-y2)
drivers-y := drivers/ sound/
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
net-y := net/
net-y := $(patsubst %/, %/built-in.o, $(net-y))
vmlinux-all := $(vmlinux-init) $(vmlinux-main)
vmlinux-init := $(head-y) $(init-y)
vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds
3 编译内核时的输出 与 makefile的对应
以下是编译内核时的输出,可以看出和makefile中的顺序几乎是一一对应的
arm-linux-ld -EL -p --no-undefined -X -o vmlinux
-T arch/arm/kernel/vmlinux.lds
arch/arm/kernel/head.o arch/arm/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o arch/arm/common/built-in.o arch/arm/mach-s3c2410/built-in.o arch/arm/mach-s3c2400/built-in.o arch/arm/mach-s3c2412/built-in.o arch/arm/mach-s3c2440/built-in.o arch/arm/mach-s3c2442/built-in.o arch/arm/mach-s3c2443/built-in.o arch/arm/nwfpe/built-in.o arch/arm/plat-s3c24xx/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 arch/arm/lib/lib.a lib/lib.a arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o
all: vmlinux
20170902更新:
3 应用实例:在内核中新增驱动代码目录和子目录
构新增如下用于 test driver 的树型目录:
|--test
|-- cpu
-- cpu.c
|-- test.c
|-- test_client.c
|-- test_ioctl.c
|-- test_proc.c
|-- test_queue.c
在内核中增加目录和子目录,我们需为相应的新增目录创建 Kconfig和 Makefile
文件,而新增目录的父目录中的 Kconfig和 Makefile 文件也需要修改,以便新增的
Kconfig 和 Makefile 文件能被引用。
在新增的 test 目录下,应该包含如下Kconfig 文件:
#
# TEST driver configuration
#
menu "TEST Driver "
comment " TEST Driver"
config CONFIG_TEST
bool "TEST support "
config CONFIG_TEST_USER
tristate "TEST user-space interface"
depends on CONFIG_TEST
endmenu
由于 TEST driver 对于内核来说是新的功能,所以首先需要创建一个菜单 TEST
Driver;然后显示“TEST support”,等待用户选择;接下来判断用户是否选择了TEST
Driver,如果是(CONFIG_TEST=y),则进一步显示子功能:用户接口与CPU 功能支
持;由于用户接口功能可以被编译成内核模块,所以这里的询问语句使用了 tristate。
为了使这个 Kconfig 文件能起作用,需要修改arch/arm/Kconfig 文件,增加以下内
source "drivers/test/Kconfig"
脚本中的 source 意味着引用新的 Kconfig 文件。
在新增的 test 目录下,应该包含如下Makefile 文件:
# drivers/test/Makefile
#
# Makefile for the TEST.
#
obj-$(CONFIG_TEST) += test.o test_queue.o test_client.o
obj-$(CONFIG_TEST_USER) += test_ioctl.o
obj-$(CONFIG_PROC_FS) += test_proc.o
obj-$(CONFIG_TEST_CPU) += cpu/
该脚本根据配置变量的取值构建 obj-*列表。由于test 目录中包含一个子目录 cpu,
当 CONFIG_ TEST_CPU=y 时,需要将cpu 目录加入列表。
test 目录中的 cpu 子目录也需包含如下的 Makefile文件:
# drivers/test/test/Makefile
#
# Makefile for the TEST CPU
#
obj-$(CONFIG_TEST_CPU) += cpu.o
为了使得整个 test 目录能够被编译命令作用到,test 目录父目录中的 Makefile 文
件也需新增如下脚本: |
obj-$(CONFIG_TEST) += test/ |
在 drivers/Makefile中加入 obj-$(CONFIG_TEST) += test/,使得用户在进行内核编 |
译时能够进入 test目录。 |
增加了 Kconfig和 Makefile 文件之后的新的 test 树型目录如下所示: |
|--test |
|-- cpu |
| -- cpu.c |
| -- Makefile |
|-- test.c |
|-- test_client.c |
|-- test_ioctl.c |
|-- test_proc.c |
|-- test_queue.c |
|-- Makefile |
|-- Kconfig |
下面我们对内核源代码各级子目录中的 kbuild Makefile 进行介绍,这部分是内核
模块或设备驱动的开发者最常接触到的。
(1)目标定义。
目标定义用来定义哪些内容要作为模块编译,哪些要编译并连接进内核。
例如:
obj-y += foo.o
表示要由 foo.c 或者 foo.s 文件编译得到foo.o 并连接进内核,而 obj-m 则表示该
文件要作为模块编译。除了 y、m以外的 obj-x 形式的目标都不会被编译。
而更常见的做法是根据.config 文件的CONFIG_变量来决定文件的编译方式,如
下所示:
obj-$(CONFIG_ISDN) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
除了 obj-形式的目标以外,还有lib-y library 库、hostprogs-y主机程序等目标,但
是基本都应用在特定的目录和场合下。
(2)多文件模块的定义。
如果一个模块由多个文件组成,这时候应采用模块名加-objs 后缀或者-y后缀的形
式来定义模块的组成文件。如下面的例子所示:
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o bitmap.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
模块的名字为 ext2,由balloc.o 和 bitmap.o 两个目标文件最终连接生成 ext2.o 直
至 ext2.ko 文件,是 否包括xattr.o 取决于内核 配置文件的配置情况。如果
CONFIG_EXT2_FS 的值是y 也没有关系,在此过程中生成的 ext2.o 将被连接进
built-in.o 最终连接进内核。这里需要注意的一点是,该kbuild Makefile 所在的目录中
不能再包含和模块名相同的源文件如 ext2.c/ext2.s。
或者写成如-objs 的形式:
obj-$(CONFIG_ISDN) += isdn.o
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
(3)目录层次的迭代。
示例:
obj-$(CONFIG_EXT2_FS) += ext2/
当 CONFIG_EXT2_FS 的值为 y 或m 时,kbuild将会把 ext2 目录列入向下迭代的
目标中,具体 ext2 目录下的文件是要作为模块编译还是链入内核由ext2 目录下的
Makefile 文件的内容决定。