Linux 驱动开发庖丁解牛之二
—— 模块编程
dreamice
e-mail:dreamice.jiang@gmail.com
本文是建立在前面的开发环境已经成功建立的基础之上的。如果没有建立好，请参照《 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, jyjiang2005@gmail.com ”);
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．后记
虽然费了很大力气写完了这篇模块编程，但总感觉欠完善，这也跟自己对内核以及驱动程序的经验和整体把握能力有关。我希望它虽然存在很多缺点，但能起到一个引线的作用，作一个总结和分析，同时是对自己阅读学习的总结，也希望对它人有所帮助，作为去深入细化研究的一个参考吧。
敬请批评指正！