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 ）
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
MODULE_LICENCE( “ Dual BSD/GPL ” );
static int hello_init(void)
{
printk(KERN_INFO "Hello world/n");
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;
struct list_head list;
char name[MODULE_NAME_LEN];
struct module_kobject mkobj;
struct module_param_attrs *param_attrs;
struct module_attribute *modinfo_attrs;
const char *version;
const char *srcversion;
const struct kernel_symbol *syms;
unsigned int num_syms;
const unsigned long *crcs;
const struct kernel_symbol *gpl_syms;
unsigned int num_gpl_syms;
const unsigned long *gpl_crcs;
const struct kernel_symbol *unused_syms;
unsigned int num_unused_syms;
const unsigned long *unused_crcs;
const struct kernel_symbol *unused_gpl_syms;
unsigned int num_unused_gpl_syms;
const unsigned long *unused_gpl_crcs;
const struct kernel_symbol *gpl_future_syms;
unsigned int num_gpl_future_syms;
const unsigned long *gpl_future_crcs;
unsigned int num_exentries;
const struct exception_table_entry *extable;
int (*init)(void);
void *module_init;
void *module_core;
unsigned long init_size, core_size;
unsigned long init_text_size, core_text_size;
void *unwind_info;
struct mod_arch_specific arch;
int unsafe;
int license_gplok;
#ifdef CONFIG_MODULE_UNLOAD
struct module_ref ref[NR_CPUS];
struct list_head modules_which_use_me;
struct task_struct *waiter;
void (*exit)(void);
#endif
#ifdef CONFIG_KALLSYMS
Elf_Sym *symtab;
unsigned long num_symtab;
char *strtab;
struct module_sect_attrs *sect_attrs;
#endif
void *percpu;
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
.long sys_init_module
.long sys_delete_module
.long sys_ni_syscall
asmlinkage long
sys_init_module(void __user *umod,
unsigned long len,
const char __user *uargs)
{
struct module *mod;
int ret = 0;
if (!capable(CAP_SYS_MODULE))
return -EPERM;
if (mutex_lock_interruptible(&module_mutex) != 0)
return -EINTR;
mod = load_module(umod, len, uargs);
if (IS_ERR(mod)) {
mutex_unlock(&module_mutex);
return PTR_ERR(mod);
}
mutex_unlock(&module_mutex);
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_COMING, mod);
if (mod->init != NULL)
ret = mod->init();
if (ret < 0) {
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();
}
mod->state = MODULE_STATE_LIVE;
wake_up(&module_wq);
mutex_lock(&module_mutex);
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;
}
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;
mod = find_module(name);
if (!mod) {
ret = -ENOENT;
goto out;
}
if (!list_empty(&mod->modules_which_use_me)) {
ret = -EWOULDBLOCK;
goto out;
}
if (mod->state != MODULE_STATE_LIVE) {
DEBUGP("%s already dying/n", mod->name);
ret = -EBUSY;
goto out;
}
if (mod->init && !mod->exit) {
forced = try_force_unload(flags);
if (!forced) {
ret = -EBUSY;
goto out;
}
}
mod->waiter = current;
ret = try_stop_module(mod, flags, &forced);
if (ret != 0)
goto out;
if (!forced && module_refcount(mod) != 0)
wait_for_zero_refcount(mod);
if (mod->exit != NULL) {
mutex_unlock(&module_mutex);
mod->exit();
mutex_lock(&module_mutex);
}
strlcpy(last_unloaded_module, mod->name, sizeof(last_unloaded_module));
free_module(mod);
out:
mutex_unlock(&module_mutex);
return ret;
}
以上就是模块实现的内核源码分析，虽然分析不够详尽，但对于编写内核模块来说，理清这么一条线，将有助于更加深入的理解模块的执行及在内核中的情况。
5．后记
虽然费了很大力气写完了这篇模块编程，但总感觉欠完善，这也跟自己对内核以及驱动程序的经验和整体把握能力有关。我希望它虽然存在很多缺点，但能起到一个引线的作用，作一个总结和分析，同时是对自己阅读学习的总结，也希望对它人有所帮助，作为去深入细化研究的一个参考吧。
敬请批评指正！
![linux-svn卸载与安装[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)