驱动编译进内核和编译模块的区别

linux内核中Kconfig文档的作用

2.6内核的源码树目录下一般都会有两个文文：Kconfig和Makefile。分布在各目录下的Kconfig构成了一个分布式的内核配置数据库，每个Kconfig分别描述了所属目录源文件相关的内核配置菜单。在内核配置make menuconfig(或xconfig等)时，从Kconfig中读出配置菜单，用户配置完后保存到.config(在顶层目录下生成)中。在内核编译时，主Makefile调用这个.config，就知道了用户对内核的配置情况。

上面的内容说明：Kconfig就是对应着内核的配置菜单。假如要想添加新的驱动到内核的源码中，可以通过修改Kconfig来增加对我们驱动的配置菜单，这样就有途径选择我们的驱动，假如想使这个驱动被编译，还要修改该驱动所在目录下的Makefile。

因此，一般添加新的驱动时需要修改的文件有两种（注意不只是两个）

*Kconfig
*Makefile

要想知道怎么修改这两种文件，就要知道两种文档的语法结构。

First:   Kconfig

 

每个菜单项都有一个关键字标识，最常见的就是config。

语法：
config symbol

options
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

symbol就是新的菜单项，options是在这个新的菜单项下的属性和选项

其中options部分有：

1、类型定义：
每个config菜单项都要有类型定义，bool：布尔类型， tristate三态：内建、模块、移除， string：字符串， hex：十六进制， integer：整型

例如config HELLO_MODULE
bool "hello test module"

bool类型的只能选中或不选中，tristate类型的菜单项多了编译成内核模块的选项，假如选择编译成内核模块，则会在.config中生成一个CONFIG_HELLO_MODULE=m的配置，假如选择内建，就是直接编译成内核影响，就会在.config中生成一个CONFIG_HELLO_MODULE=y的配置.

2、依赖型定义depends on或requires
指此菜单的出现是否依赖于另一个定义

config HELLO_MODULE
bool "hello test module"
depends on ARCH_PXA
    这个例子表明HELLO_MODULE这个菜单项只对XScale处理器有效，即只有在选择了ARCH_PXA， 该菜单才可见(可配置)。

3、帮助性定义
只是增加帮助用关键字help或---help---
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

更多详细的Kconfigconfig语法可参考：

Second:  内核的Makefile

内核的Makefile分为5个组成部分： 
Makefile     最顶层的Makefile 
.config        内核的当前配置文档，编译时成为顶层Makefile的一部分
arch/$(ARCH)/Makefile 和体系结构相关的Makefile 
s/ Makefile.*    一些Makefile的通用规则 
kbuild Makefile      各级目录下的大概约500个文档，编译时根据上层Makefile传下来的宏定义和其他编译规则，将源代码编译成模块或编入内核。

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

（其中.config的内容是在make menuconfig的时候，通过Kconfig文档配置的结果）

在linux2.6.x/Documentation/kbuild目录下有详细的介绍有关kernel 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时，您将发现ap71 flash选项，假如您选择了此项。该选择就会保存在.config文档中。当您编译内核时，将会读取.config文档，当发现ap71 flash 选项为yes 时，系统在调用/driver/mtd/maps/下的makefile 时，将会把 flashtest.o 加入到内核中。即可达到您的目的。

转载： http://blog.csdn.net/aaronychen/article/details/2946740

 

 

我们都知道驱动可以编译成module和直接编译进内核，那么这两者到底有什么区别？

从驱动的入口函数来看，两者都是一样的，都是module_init（）；

在linux/init.h中可以看到，以下代码：

1. #ifndef MODULE  
2.  
3. #ifndef __ASSEMBLY__   
4.   
5. /* initcalls are now grouped by functionality into separate  
6.  * subsections. Ordering inside the subsections is determined 
7.  * by link order.  
8.  * For backwards compatibility, initcall() puts the call in  
9.  * the device init subsection. 
10.  * 
11.  * The `id' arg to __define_initcall() is needed so that multiple initcalls 
12.  * can point at the same handler without causing duplicate-symbol build errors. 
13.  */ 
14.  
15. #define __define_initcall(level,fn,id) /  
16.     static initcall_t __initcall_##fn##id __attribute_used__ /  
17.     __attribute__((__section__(".initcall" level ".init"))) = fn  
18. ....................  
19. ....................  
20. #define __initcall(fn) device_initcall(fn)  
21.  
22. #define __exitcall(fn) /   
23.     static exitcall_t __exitcall_##fn __exit_call = fn  
24. .....................  
25. #else /* MODULE */   
26. /* Each module must use one module_init(), or one no_module_init */ 
27. #define module_init(initfn)                 /  
28.     static inline initcall_t __inittest(void)       /  
29.     { return initfn; }                  /  
30.     int init_module(void) __attribute__((alias(#initfn)));  
31.   
32. /* This is only required if you want to be unloadable. */ 
33. #define module_exit(exitfn)                 /  
34.     static inline exitcall_t __exittest(void)       /  
35.     { return exitfn; }                  /  
36.     void cleanup_module(void) __attribute__((alias(#exitfn)));  

当我们选择将驱动编译成模块时，那么MODULE宏就会被定义；

如果没有定义MODULE宏，那么驱动初始化函数就会带有.initcall6.init属性，那么在其编译时将会被安排到__initcall_start和__initcall_end范围之间（可以参考内核源码目录下的内核链接脚本arch/cpu-type/kernel/vmlinux.lds.S，其中cpu-type可以是mips、arm、i386等），

 

__initcall_start = .;  

1.   .initcall.init : {  
2.     INITCALLS  
3.   }  
4.   __initcall_end = .;  
5.   
6. 而INITCALLS宏定义在include/asm-generic/Vmlinux.lds.h中：  
7. #define INITCALLS                           /  
8.     *(.initcall0.init)                      /  
9.     *(.initcall0s.init)                     /  
10.     *(.initcall1.init)                      /  
11.     *(.initcall1s.init)                     /  
12.     *(.initcall2.init)                      /  
13.     *(.initcall2s.init)                     /  
14.     *(.initcall3.init)                      /  
15.     *(.initcall3s.init)                     /  
16.     *(.initcall4.init)                      /  
17.     *(.initcall4s.init)                     /  
18.     *(.initcall5.init)                      /  
19.     *(.initcall5s.init)                     /  
20.     *(.initcallrootfs.init)                     /  
21.     *(.initcall6.init)                      /  
22.     *(.initcall6s.init)                     /  
23.     *(.initcall7.init)                      /  
24.     *(.initcall7s.init)  

在kernel启动时，会执行如下函数：

init->do_basic_setup->do_initcalls

do_initcalls中会把.initcall.init中的函数依次执行一遍

for (call = __initcall_start; call < __initcall_end; call++) {

 

...

 

(*call)();

 

...

 

}

于是在内核启动过程中执行了module_init(fn)函数，也就实现了自动加载模块的目的；

这类似于pmon中带有constructor属性的函数，都是在编译时统一将其安排到某一连续的地址范围内，然后再启动时，遍历执行这些函数。

 

****************************************************************************************************************************************************************************************

***编译成模块时，模块也有版本号！在模块的Makefile中有编译该模块使用的内核版本号。或者在当前编译这个模块的内核源代码中也可以看到内核版本号。这个版本号即为所编译的模块的版本号！
当用insmod将模块加载进某个内核时，模块版本号必须要与该内核版本号一致，当然也可以用modprobe命令来强行插入。
注意前后两个内核版本号是针对不同的内核的，前者是针对编译模块时用的内核，后者是模块加载进内核时的内核（即利用该模块的某个内核）。

 

 

***字符设备和块设备跟文件系统打交道，他们服务于 文件系统，所以只需要关心文件系统。

***网络设备和协议栈打交道，他们服务于协议栈，所 以只需要关心协议栈。