Linux驱动开发庖丁解牛之二 ——模块编程

Linux 驱动开发庖丁解牛之二 

—— 模块编程 

dreamice 

e-mail:[email protected] 

本文是建立在前面的开发环境已经成功建立的基础之上的。如果没有建立好，请参照《 Linux 驱动开发庖丁解牛之一 —— 开发环境的建立》。 

已经有很多文档讲述模块编程，个人觉得《 The Linux kernel module programming guide 》是最详尽的。本文不再立足于从理论上去阐述模块编程的相关知识，而着重从实践的基础上去掌握模块编程，领悟模块编程的实质。当然，具备足够的理论知识才能从实践出发，所以，本文档尽量配合《 Linux Device Driver 》第三版的第二章，以及讲述模块编程最完善的文档《 The Linux kernel module programming guide 》。下面，我们从实践开始出发吧。 

1.  人之初（ hello world ） 

/* 

* hello.c - The first kernel module programming 

*/ 

#include <linux/module.h> /* Needed by all modules */ 

#include <linux/kernel.h> /* Needed for KERN_ALERT */ 

#include <linux/init.h> 

MODULE_LICENCE( “ Dual BSD/GPL ” ); 

static int hello_init(void) 

{ 

printk(KERN_INFO "Hello world/n"); 

/* 

* A non 0 return means init_module failed; module can't be loaded. 

*/ 

return 0; 

} 

static void hello_exit(void) 

{ 

printk(KERN_INFO "Goodbye world/n"); 

} 

module_init(hello_init); 

module_exit(hello_exit); 

MODULE_AUTHOR(“dreamice,  [email protected] ”); 

MODULE_DESCRIPTION(“The first module program”); 

MODULE_VERSION(“V1.0”); 

MODULE_ALIAS(“Chinese: ren zhi chu”); 

Makefile: 

obj-m := hello.o 

KERNELDIR ?= /lib/modules/$(shell uname -r)/build 

PWD := $(shell pwd) 

default: 

$(MAKE) -C $(KERNELDIR) M=$(PWD) modules 

clean: 

$(RM) *.o *.ko *.mod.c Module.symvers 

现在，我们一步一步来解析这个最简单的hello world 模块程序。 

1． /linux/module.h  这个是必须的。这个头文件包含了对模块结构的定义以及相关信息。 

2． module_init  和 module_exit 这两个函数是必须的。 module_init 就好比应用程序的 main 函数，没有 main 函数，应用程序将不知道从哪里开始执行。 

3．关于 printk ，在 ldd3 的第四章有详细的说明，这个可以说是内核调试的一个基本手段。 

4． MODULE_LICENCE ， MODULE_AUTHOR ， MODULE_DESCRIPTION ， MODULE_VERSION ， MODULE_ALIA ，分别是模块许可证，模块作者、描述、版本以及别名的描述，除了许可证这个比较正式以外（遵循 GPL ），其它几个主要是用作开发者的一些控制和描述信息，使用比较灵活。 

5． Makefile ，很特别，不同于一般的应用程序的 Makefile 。首先，模块编译的目标必须以 obj-m 这样的形式指出；其次，模块的编译必须指定内核源代码的路径 —— 这也是模块运行在内核空间的一个原因。模块有多个源文件生成的情况可如下编写： 

obj-m := module.o 

module-objs := file1.o file2.o 

6． module_exit 为模块推出执行清理的函数。如果模块加载后不允许卸载，那么这个函数就不用实现了。 

2. 模块常见错误 

处理错误常常是程序员比较头痛的事情，这里我把比较常见的一些模块编译错误罗列一下，可能不是很全面。 

1．  Invalid module format 

这个通常是版本不一致问题导致的。比如说，你在2.4 内核上编译的模块，如果运行到 2.6 版的内核，有可能就会出现这样的提示。 

另外可以尝试一下，把一个普通文件改名为hello.ko,  执行 insmod hello.ko ，也会报

这个错误。 

2．  Unresolved symbol…… 

这个错误常常是你引用的某个函数可能出了问题。如引用内核模块并没有导出的函数。在这里，顺便把模块符号导出描述一下： 

EXPROT_SYMBOL(name) 

EXPROT_SYMBOL_GPL(name) 

如果一个模块希望另一个模块引用自己的函数，那么必须使用以上两个函数导出符号，否则，其它模块是不能引用的。就会报这个错误了。 

3． 这个错误不是编译问题的错误： 

模块运行于内核空间，所以，不能引用标准库函数，也不能处理浮点数。如果不加注意，可能导致一些无法预知的错误。 

4． 由于内核版本升级，导致一些结构体的改变，如果在低版本的内核上编写模块，到高版本编译，就可能出现 “no such member……” 类似的错误。 

Linux驱动程序的开发者无非处于两种情况： 

1． 对一个全新的硬件编写驱动程序。这种情况需要对该版本内核的相关部分有充分了解。程序员的精力既要考虑模块功能的设计实现，又要考虑内核的接口功能等等。 

2． 移植一个驱动程序。往往从低版本到高版本或者高版本到低版本的移植。这种情况下，需要对两个版本的内核有一个充分的认识，就是可能有些结构体，或者函数接口变化的问题。程序员往往不需要花太多的精力在模块功能的实现上，而更多的精力在版本差异上。 

3. 模块层叠技术 

关于模块层叠技术很多书上介绍的比较简略。模块层叠技术，主要指模块的依赖关系，如模块A 的实现依赖于 B ，如果 B 并没有加载，那么，当 insmod A 的时候，将无法成功。这个时候，就必须使用 modprobe A ，把相关的模块统统加载到内核，即 B 也得到了加载。我们尽量不要使用 modprobe –r 来移出一个模块，因为这将导致相关联的模块都被移出。 

4．模块实现的内核代码分析 

1．数据结构 

模块相关的数据结构存放在include/linux/module.h 

struct module 

{ 

enum module_state state; 

/* Member of list of modules */ 

struct list_head list; 

/* Unique handle for this module */ 

char name[MODULE_NAME_LEN]; 

/* Sysfs stuff. */ 

struct module_kobject mkobj; 

struct module_param_attrs *param_attrs; 

struct module_attribute *modinfo_attrs; 

const char *version; 

const char *srcversion; 

/* Exported symbols */ 

const struct kernel_symbol *syms; 

unsigned int num_syms; 

const unsigned long *crcs; 

/* GPL-only exported symbols. */ 

const struct kernel_symbol *gpl_syms; 

unsigned int num_gpl_syms; 

const unsigned long *gpl_crcs; 

/* unused exported symbols. */ 

const struct kernel_symbol *unused_syms; 

unsigned int num_unused_syms; 

const unsigned long *unused_crcs; 

/* GPL-only, unused exported symbols. */ 

const struct kernel_symbol *unused_gpl_syms; 

unsigned int num_unused_gpl_syms; 

const unsigned long *unused_gpl_crcs; 

/* symbols that will be GPL-only in the near future. */ 

const struct kernel_symbol *gpl_future_syms; 

unsigned int num_gpl_future_syms; 

const unsigned long *gpl_future_crcs; 

/* Exception table */ 

unsigned int num_exentries; 

const struct exception_table_entry *extable; 

/* Startup function. */ 

int (*init)(void); 

/* If this is non-NULL, vfree after init() returns */ 

void *module_init; 

/* Here is the actual code + data, vfree'd on unload. */ 

void *module_core; 

/* Here are the sizes of the init and core sections */ 

unsigned long init_size, core_size; 

/* The size of the executable code in each section. */ 

unsigned long init_text_size, core_text_size; 

/* The handle returned from unwind_add_table. */ 

void *unwind_info; 

/* Arch-specific module values */ 

struct mod_arch_specific arch; 

/* Am I unsafe to unload? */ 

int unsafe; 

/* Am I GPL-compatible */ 

int license_gplok; 

#ifdef CONFIG_MODULE_UNLOAD 

/* Reference counts */ 

struct module_ref ref[NR_CPUS]; 

/* What modules depend on me? */ 

struct list_head modules_which_use_me; 

/* Who is waiting for us to be unloaded */ 

struct task_struct *waiter; 

/* Destruction function. */ 

void (*exit)(void); 

#endif 

#ifdef CONFIG_KALLSYMS 

/* We keep the symbol and string tables for kallsyms. */ 

Elf_Sym *symtab; 

unsigned long num_symtab; 

char *strtab; 

/* Section attributes */ 

struct module_sect_attrs *sect_attrs; 

#endif 

/* Per-cpu data. */ 

void *percpu; 

/* The command line arguments (may be mangled). People like 

keeping pointers to this stuff */ 

char *args; 

}; 

在内核中，每一个内核模块都由这样一个module 对象来描述。所有的 module 对象由一个链表链接在一起，其中每个对象的 next 域都指向链表的下一个元素。 

State 表示 module 当前的状态 , 主要包括一下几种状态： 

MODULE_STATE_LIVE 

MODULE_STATE_COMING 

MODULE_STATE_GOING 

其中，加载后的模块的状态为MODULE_STATE_LIVE 。 

name保存 module 的名字； 

param_attrs指向 module 可传递的参数的名称及属性； 

init和 exit 这两个函数指针，可以看作是 hello world 对应的 init 和 exit 函数，即模块初始化和模块退出所调用的函数； 

struct list_head modules_which_use_me这个成员是一个链表，指示了所有依赖于该模块的模块。 

下面我们继续看看模块的加载和退出函数。 

操作系统在初始化时，调用static LIST_HEAD(modules) 建立了一个空链表，之后，每装入一个内核模块，即创建一个 struct module 结构，并把它链入 modules 这个全局的链表中。 

从操作系统内核的角度来说，它提供的用户服务，都是通过系统调用来实现的。实际上，我们在调用module_init 和 module_exit 时，都是首先需要通过这两个系统调用来实现的： sys_init_module(), sys_delete_module() 。我使用的是比较新的 2.6.25 的内核源码。在内核源码： arch/x86/kernel/ syscall_table_32.S, 我们看到这两个系统调用的函数： 

………… 

.long sys_sigprocmask 

.long sys_ni_syscall /* old "create_module" */ 

.long sys_init_module 

.long sys_delete_module 

.long sys_ni_syscall /* 130: old "get_kernel_syms" * 

…………. 

在kernel/module.c 中，我们来看这两个函数的具体实现： 

/* This is where the real work happens */ 

/* umod指向用户空间中该内核模块 image 所在的位置。 Image 以 elf 的可执行文件格式保存， image 的最前部是 elf_ehdr 类型结构，长度由 len 指示。 Uargs 指向来自用户空间的参数。 */ 

asmlinkage long 

sys_init_module(void __user *umod, 

unsigned long len, 

const char __user *uargs) 

{ 

struct module *mod; 

int ret = 0; 

/* Must have permission */ 

/*验证是否有权限装入内核模块 */ 

if (!capable(CAP_SYS_MODULE)) 

return -EPERM; 

/* Only one module load at a time, please */ 

/*一个时候，只能有一个内核模块在加载中 … 这可能也是为了保持内核模块链表的独占式访问 */ 

if (mutex_lock_interruptible(&module_mutex) != 0) 

return -EINTR; 

/* Do all the hard work */ 

/*真正的内核模块加载的实现函数，包括物理内存的分配， image  的检查等等，这个函数实现比较庞大复杂，这里不作细致分析了 … 这里之后，模块的 state 也变成了 MODULE_STATE_COMING */ 

mod = load_module(umod, len, uargs); 

if (IS_ERR(mod)) { 

mutex_unlock(&module_mutex); 

return PTR_ERR(mod); 

} 

/* Drop lock so they can recurse */ 

mutex_unlock(&module_mutex); 

blocking_notifier_call_chain(&module_notify_list, 

MODULE_STATE_COMING, mod); 

/* Start the module */ 

if (mod->init != NULL) 

ret = mod->init(); /*执行模块的初始化工作 …*/ 

if (ret < 0) {/*初始化失败 */ 

/* Init routine failed: abort. Try to protect us from 

buggy refcounters. */ 

/*模块加载不成功，设置成 MODULE_STATE_GOING  ，因为稍后将作清除处理 */ 

mod->state = MODULE_STATE_GOING; 

synchronize_sched(); 

module_put(mod); 

mutex_lock(&module_mutex); 

free_module(mod); 

mutex_unlock(&module_mutex); 

wake_up(&module_wq); 

return ret; 

} 

if (ret > 0) { 

printk(KERN_WARNING "%s: '%s'->init suspiciously returned %d, " 

"it should follow 0/-E convention/n" 

KERN_WARNING "%s: loading module anyway.../n", 

__func__, mod->name, ret, 

__func__); 

dump_stack(); 

} 

/* Now it's a first class citizen! Wake up anyone waiting for it. */ 

mod->state = MODULE_STATE_LIVE; /*模块加载成功后，状态变成 _LIVE 了 */ 

wake_up(&module_wq); 

mutex_lock(&module_mutex); 

/* Drop initial reference. */ 

module_put(mod); 

unwind_remove_table(mod->unwind_info, 1); 

module_free(mod, mod->module_init); 

mod->module_init = NULL; 

mod->init_size = 0; 

mod->init_text_size = 0; 

mutex_unlock(&module_mutex); 

return 0; 

} 

/* name_user 是要删除的模块名称，前面的 __user 说明这是一个用户空间的名称 */ 

asmlinkage long 

sys_delete_module(const char __user *name_user, unsigned int flags) 

{ 

struct module *mod; 

char name[MODULE_NAME_LEN]; 

int ret, forced = 0; 

/*权限检查 */ 

if (!capable(CAP_SYS_MODULE)) 

return -EPERM; 

/*把模块名称从用户空间传递到内核空间 */ 

if (strncpy_from_user(name, name_user, MODULE_NAME_LEN-1) < 0) 

return -EFAULT; 

name[MODULE_NAME_LEN-1] = '/0'; 

if (mutex_lock_interruptible(&module_mutex) != 0) 

return -EINTR; 

/*查找要删除的 module*/ 

mod = find_module(name); 

if (!mod) { 

ret = -ENOENT; 

goto out; 

} 

/*如果还有其它模块正在使用该模块，则不能把该模块删除 */ 

if (!list_empty(&mod->modules_which_use_me)) { 

/* Other modules depend on us: get rid of them first. */ 

ret = -EWOULDBLOCK; 

goto out; 

} 

/* Doing init or already dying? */ 

if (mod->state != MODULE_STATE_LIVE) { 

/* FIXME: if (force), slam module count and wake up 

waiter --RR */ 

DEBUGP("%s already dying/n", mod->name); 

ret = -EBUSY; 

goto out; 

} 

/* If it has an init func, it must have an exit func to unload */ 

if (mod->init && !mod->exit) { 

forced = try_force_unload(flags); 

if (!forced) { 

/* This module can't be removed */ 

ret = -EBUSY; 

goto out; 

} 

} 

/* Set this up before setting mod->state */ 

mod->waiter = current; 

/* Stop the machine so refcounts can't move and disable module. */ 

ret = try_stop_module(mod, flags, &forced); 

if (ret != 0) 

goto out; 

/* Never wait if forced. */ 

if (!forced && module_refcount(mod) != 0) 

wait_for_zero_refcount(mod); 

/* Final destruction now noone is using it. */ 

if (mod->exit != NULL) { 

mutex_unlock(&module_mutex); 

mod->exit(); /* 这里相当于执行模块的 exit 函数，执行后续的清理工作 ……*/ 

mutex_lock(&module_mutex); 

} 

/* Store the name of the last unloaded module for diagnostic purposes */ 

strlcpy(last_unloaded_module, mod->name, sizeof(last_unloaded_module)); 

free_module(mod); 

out: 

mutex_unlock(&module_mutex); 

return ret; 

} 

以上就是模块实现的内核源码分析，虽然分析不够详尽，但对于编写内核模块来说，理清这么一条线，将有助于更加深入的理解模块的执行及在内核中的情况。 

5．后记 

虽然费了很大力气写完了这篇模块编程，但总感觉欠完善，这也跟自己对内核以及驱动程序的经验和整体把握能力有关。我希望它虽然存在很多缺点，但能起到一个引线的作用，作一个总结和分析，同时是对自己阅读学习的总结，也希望对它人有所帮助，作为去深入细化研究的一个参考吧。 

敬请批评指正！