Makefile与Kconfig和.config关系与使用

来源:互联网 发布:咖啡厅收银软件 编辑:程序博客网 时间:2024/05/18 00:04

 文章转自 http://blog.sina.com.cn/s/blog_4a377e150100c896.html

          http://blog.sina.com.cn/s/blog_4a70d5d90101261k.html


    内核源码树的目录下都有两个文档 Kconfig(2.4版本是Config.in)和Makefile。分布到各目录的Kconfig构成了一个分布式的内核配置数据库,每个Kconfig分别描述了所属目录源文档相关的内核配置菜单。

   在内核配置make mini2440_defconfig时,arch/arm/configs/mini2440_defconfig 复制生.config,这时使用的是默认配置,再make zImage即可生成内核

   在内核配置make menuconfig时,从Kconfig中读出菜单,用户选择后保存到.config的内核配置文档中。并且生成相应的C语言格式的文件,在/include/linux/version.h,autoconfig.h。当make distclean 时会删除掉这些文件。

  在内核编译make zImage时,主Makefile调用这个.config,就知道了用户的选择。

 

   上面的内容说明了,Kconfig就是对应着内核的配置菜单。假如要想添加新的驱动到内核的源码中,能够修改Kconfig,这样就能够选择这个驱动,假如想使这个驱动被编译,要修改Makefile。所以,添加新的驱动时需要修改的文档有两种(注意不只是两个)
*Kconfig
*Makefile

---------------------------------------------------------------------------------------------
Kconfig

1.先了解一下Kconfig的语法:
一个典型的内核配置菜单如下:
menu "Network device support"
config NETDEVICES
bool "Enable Net Devices"
depends on NET
default y
help
This is help desciption。
...
endmenu
包含在menu/endmenu中的内容会成为Network device support的子菜单。每一个子菜单项都是由config来定义的。congfig下方的那些bool、dependson、default、help等为config的属性,用于定义该菜单项的类型、依赖项、默认值、帮助信息等。

2. 补充说明一下类型定义部分:
每个config菜单项都要有类型定义: bool布尔类型(y或ndepend则表示依赖项)、tristate三态(编译进内核(y),编译成模块(m),不编译(n))、string字符串、hex十六进制、integer整型。
例如:
config HELLO_MODULE
bool "hello test module"
bool 类型的只能选中或不选中,显示为[]; tristate类型的菜单项多了编译成内核模块的选项,显示为<> , 假如选择编译成内核模块,则会在.config中生成一个CONFIG_HELLO_MODULE=m的配置,假如选择内建,就是直接编译成内核影响,就会在.config中生成一个CONFIG_HELLO_MODULE=y的配置. hex十六进制类型显示为( )。

<> 里的"*"表示把指定选项编译到内核,"   "表示不对指定选项做任何操作,"M"表示把指定的选项编译成模块。(可按空格键来更换选择这三项 )


depends on:表示依赖于XXX,“depends on NET”表示只有当NETDEVICES配置选项被选中时,当前配置选项的提示信息才会出现,才能设置当前配置选项


default 缺省的编译选项 以上表示默认为 Y


3. 目录层次迭代
在Kconfig中有类似语句:source"drivers/usb/Kconfig"
用来包含(或嵌套)新的Kconfig文件,这样便可以使各个目录管理各自的配置内容,使不必把那些配置都写在同一个文件里,方便修改和管理。

----------------------------------------------------------------------------------------------Makefile

2.6内核的Makefile分为5个组成部分:

1. 最顶层的Makefile
2. 内核的.config配置文件
3. 在arch/$(ARCH) 目录下的体系结构相关的Makefile
4. 在s目录下的 Makefile.* 文件,是一些Makefile的通用规则
5. 各级目录下的大概约500个kbuild Makefile文件

顶层的Makefile文件读取 .config文件的内容,并总体上负责build内核和模块。ArchMakefile则提供补充体系结构相关的信息。 s目录下的Makefile文件包含了所有用来根据kbuild Makefile构建内核所需的定义和规则。

Kbuild Makefile
对于Makefiles的不同组成部分,有一些不同的语法规则。针对的对象也不同,对于大部分内核模块或设备驱动的开发者和使用者来说,最常接触到的就是各层目录下基于kbuild架构的kbuildMakefile文件。Kbuild Makefile核心内容主要包括:

1.目标定义
目标定义就是用来定义哪些内容要做为模块编译,哪些要编译链接进内核。如:

obj-y += foo.o

表示要由foo.c或者foo.s文件编译得到foo.o并链接进内核,而obj-m则表示该文件要作为模块编译。除了y,m以外的obj-x形式的目标都不会被编译。而更常见的做法是根据.config文件的CONFIG_变量来决定文件的编译方式(该变量如何起作用见文末另一篇文章的链接),如:
obj-$(CONFIG_EXT2) += ext2.o

除了obj-形式的目标以外,还有lib-y library库,hostprogs-y主机程序等目标,但是基本都应用在特定的目录和场合下。

2.多文件模块的定义
最简单的kbuild Makefile如上一节一句话的形式就够了,如果一个模块由多个文件组成,那么稍微复杂一些,采用模块名加–objs后缀或者 –y后缀的形式来定义模块的组成文件。如以下例子:
obj-$(CONFIG_EXT2) += ext2.o
ext2-y := balloc.o bitmap.o

或者写成如-objs的形式:
obj-$(CONFIG_EXT2) += ext2.o
ext2-objs := balloc.o bitmap.o

模块的名字为ext2,如果CONFIG_EXT2 的值是m,由balloc.o和bitmap.o两个目标文件最终链接生成ext2.o直至ext2.ko文件,如果CONFIG_EXT2的值是y,生成的 ext2.o将被链接进built-in.o最终链接进内核。

3.目录层次的迭代
如下例:
obj-$(CONFIG_EXT2) += ext2/

如果CONFIG_EXT2 的值为y或m,kbuild将会将ext2目录列入向下迭代的目标中。

----------------------------------------------------------------------------------------------
模块的编译

编译模块的时候,你可以将模块放在代码树中,用Makemodules的方式来编译你的模块
此时Makefile内容很简单,例如:obj-$(CONFIG_EXT2)+= ext2.o 即可。

你也可以将模块相关文件目录放在代码树以外的位置,用如下命令来编译模块:
make -C <path tokernel src> M=$PWD modules

‘-C’指定代码树的位置,M=$PWD 或 M=`PWD` 告诉kbuild回到当前目录来执行build操作。
当然,我们也可以为其写一个Makefile,这里介绍一个教通用的Makefile(2.6版本):

# Makefile2.6
ifneq ($(KERNELRELEASE),)
#kbuild syntax. dependency relationshsip of files and targetmodules are listed here.
obj-m := hello.o
hello-objs := hello.o
else
PWD := $(shell pwd)
KDIR := /lib/modules/$(shell uname -r)/build
all:
$(MAKE) -C $(KDIR) M=$(PWD) modules
clean:
rm -rf .*.cmd *.o *.mod.c *.ko.tmp_versions
endif

此例子驱动目录叫做hello,实际中需要将下面的hello换成自己的目录名称。其中代码树路径是自动获取的。之后在目录下直接执行make命令即可,不再用敲上面一大长串命令。

----------------------------------------------------------------------------------------------
在添加新驱动时,需要创建Kconfig、Makefile文件,且需要修改父目录Kconfig、Makefile这两个文件以便将自己的驱动包含进去。


/*自己建一个驱动程序 */

  假设想把自己写的一个flash的驱动程式加载到工程中,而且能够通过menuconfig配置内核时选择该驱动该怎么办呢?能够分三步:

第一:将您写的flashtest.c文档添加到/driver/mtd/maps/ 目录下。

第二:修改/driver/mtd/maps目录下的kconfig文档:
config MTD_flashtest
tristate “ap71 flash"

这样当make menuconfig时,将会出现 ap71 flash选项。

第三:修改该目录下makefile文档。
添加如下内容:obj-$(CONFIG_MTD_flashtest)+=flashtest.o

这样,当您运行make menucofnig时,您将发现ap71flash选项,假如您选择了此项。该选择就会保存在.config文档中。当您编译内核时,将会读取.config文档,当发现ap71flash 选项为yes 时,系统在调用/driver/mtd/maps/下的makefile 时,将会把 flashtest.o加入到内核中。即可达到您的目的。




例子:
假设我们要在内核源代码drivers 目录下如下用于 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 EST

bool "TEST suport"

 

config TEST_USER tristate "TEST user-space interface"

depends on CONFIG_TEST

endmenu

由于 TEST Driver 对于内核来说是新的功能,所以首先需要创建一个菜单 TEST Driver ;然后显示 "TESTsupport " ,等待用户选择;接下来判断用户是否选择了 TEST Driver ,如果是(CONFIG_TEST=y),则进一步显示子功能:用户接口与CPU功能支持;由于用户接口功能可以被编译成内核模块,所以这里的询问语句使用了tristate. 为了使这个 Kconfig 文件能起作用,需要修改 drivers/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/cpu/Makefile #

# Makefile for the TEST cpu #

obj-$(CONFIG_TEST_CPU) += cpu.o

为了使得整个 test 目录能够被编译命令作用到, test 目录父目录中的 Makefile 文件也需新增如下脚本:obj-$(CONFIG_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


在linux2.6.x/Documentation/kbuild目录下有周详的介绍有关kconfig、makefile的知识。

----------------------------------------------------------------------------------------------
详解Makefile

假如有一个上百个文件的代码构成的项目,如果只是对其中一个或少数几个文件进行了修改,若用gcc编译工具就不得不把整个项目里的文件重新编译一遍。
编译过程分为编译、汇编链接等阶段。其中,编译阶段仅检查语法错误以及函数与变量的声明是否正确,在链接阶段则主要完成函数链接和全局变量的链接。因此,没有改动的源代码根本不需要重新编译,而只需将它们重新链接进去就可以了
make工程管理器是一个“自动编译管理器”,这里的“自动”是指它能够根据文件时间戳自动发现更新过的文件而减少编译的工作量。同时,它通过读入makefile文件的内容来执行大量的编译工作。用户只需编写一次简单的编译语句就可以了。

1. 编写makefile文件

makefile的书写规则:
目标文件依赖文件
(TAB)产生目标文件的命令
注意:
gcc前面的空格是用TAB生成,而不是按空格键。

2. 使用makefile编译文件的操作步骤

  • 编写代码,分成多个文件
例如:
分成文件 2-5-main.c,2-5-fun1.c,2-5-fun2.c,my.h
  • 编辑makefile文件

例如:
2-5:2-5-main.o 2-5-fun1.o 2-5-fun2.c
gcc 2-5-main.o 2-5-fun1.o 2-5-fun2.o -o 2-5
2-5-main.o:2-5-main.c my.h
gcc 2-5-main.c -c
2-5-fun1.o:2-5-fun1.c
gcc 2-5-fun1.c -c
2-5-fun2.o:2-5-fun2.c
gcc 2-5-fun2.c -c

在编辑makefile文件时可以自定义一些变量来代表一串文字,例如
CC=gcc
objects=2-5-main.o 2-5-fun1.o 2-5-fun2.o
2-5:$(objects)
$(CC) $(objects) -o 2-6
..........

区别一下:

   :左侧是变量,右侧是值,值可以定义于文件任何处(一般取最后一次定义处)

:=   :左侧是变量,右侧是值,值只能定义于文件之前(一般取之前最后一个)
?=   :左侧是变量,右侧是值,如果变量未定义则赋值,如果定义了则什么都不做

+=   :追加


在这个makefile文件中,目标文件(target)包含可执行文件2-5和中间目标文件(*.o)。依赖文件(prerequisites)包含冒号后面大的那些.c文件和.h文件。每一个.o文件都有一组依赖文件,而这些.o文件又是可执行文件2-5的依赖文件。依赖关系的实质是说明目标文件由哪些文件生成。在定义好依赖关系后,后续的代码定义如何生成目标文件的操作系统命令,其一定要以一个Tab键作为开头。

  • 用make命令编译
编写好makefile文件后,用make命令编译,指定makefile文件需要在make后面加参数-f,例如:
make -fmakefile2-5

在默认方式下,只输入make命令,其会做如下工作:
1) make会在当前目录下查找名字为makefile的文件或“makefile文件夹”的文件。如果找到,它会找文件中的第一个目标文件(target)。如果该目标文件不存在,或是该目标文件所依赖的.o文件的修改时间比它新,就会执行后面所定义的命令来生成第一个目标文件。
2)如果第一个目标文件所依赖的.o文件也存在,make会在当前文件中找目标为.o文件的依赖性,如果找到,则会根据规则生成.o文件。
3)c文件和h文件如果存在,make会生成.o文件,然后再用.o文件生成make的最终结果,也就是可执行文件,即第一个目标文件。
这就是整个make的依赖性,make会一层又一层地去找文件的依赖性,直到最终编译出第一个目标文件。在寻找的过程中,如果出现错误,则make会直接退出,并报错。对所定义的命令的错误,或是编译不成功,make就不会处理。如果在make找到了依赖关系之后,冒号后面的文件不存在,make仍不工作(这就是伪目标.PHONY,需要make伪目标 来执行)
0 0
原创粉丝点击