内核模块管理
Linux设备驱动会以内核模块的形式出现，因此学会编写Linux内核模块编程是学习linux设备驱动的先决条件。
Linux内核的整体结构非常庞大，其包含的组件非常多。我们把需要的功能都编译到linux内核,以模块方式扩展内核功能。
先来看下最简单的内核模块
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
#include <linux/init.h> #include <linux/module.h> static int __init hello_init(void) { printk(KERN_ALERT "Hello world! %s, %d
", __FILE__, __LINE__); return 0; } static void __exit hello_exit(void) { printk(KERN_ALERT "Hello world! %s, %d
", __FILE__, __LINE__); } module_init(hello_init); module_exit(hello_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Mikcy Liu"); MODULE_DESCRIPTION("A simple Module"); MODULE_ALIAS("a simple module"); |
头文件init.h包含了宏_init和_exit，它们允许释放内核占用的内存。
module_init()和hello_exit()是模块编程中最基本也是必须的两个函数。
module_init()是驱动程序初始化的入口点。
hello_exit是模块的退出和清理函数。此处可以做所有终止该驱动程序时相关的清理工作。
内核模块中用于输出的函数式内核空间的printk()而非用户空间的printf(),printk()的用法和printf()相似，但前者可定义输出级别。printk()可作为一种最基本的内核调试手段
前者可以定义输出级别,在 <内核目录>/include/linux/kernel.h中
|
1
2
3
4
5
6
7
8
|
#define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ |
未设定级别的，在<内核目录>/kernel/printk.c中定义
|
1
2
3
|
/* printk's without a loglevel use this.. */#define DEFAULT_MESSAGE_LOGLEVEL 4 /* KERN_WARNING */ #define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ |
只有当printk打印信息时的loglevel小于DEFAULT_CONSOLE_LOGLEVEL的值（优先级高于console loglevel），这些信息才会被打印到console上。
模块声明与描述
- 在linux模块中，我们可以使用
- MODULE_LICENSE(license) //定义模块的license，一般为GPL，或相关公司的license
- MODULE_AUTHOR //模块的作者
- MODULE_DESCRIPTION //对模块程序的描述，string
- MODULE_VERSION //版本
- MODULE_DEVICE_TABLE //模块程序所支持的设备，string
- MODULE_ALIAS //别名
- MODULE_PARM(var,type) //模块参数
模块编译
首先看看Makefile文件：
|
1
2
3
4
5
6
7
|
obj-m := hello.o KERNEL_BUILD := /lib/modules/$(shell uname -r)/build all: make -C $(KERNEL_BUILD) M=$(shell pwd) modules clean: -rm -rf *.o *.ko *.mod.c .*.cmd *.order *.symvers .tmpversions KERNELBUILD :=/lib/modules/$(shell uname -r)/ |
build是编译内核模块需要的Makefile的路径，Ubuntu下是/lib/modules/2.6.31-14-generic/build
如果是Arm平台的开发板,则-C选项指定的位置(即内核源代码目录),其中保存有内核的顶层Makefile文件.
make -C $(KERNEL_BUILD) M=$(shell pwd) modules 编译内核模块。-C 将工作目录转到KERNEL_BUILD，调用该目录下的Makefile，并向这个Makefile传递参数M的值是$(shell pwd) modules。
M=选项让该makefile在构造modules目标之前返回到模块源代码目录。然后modules目标指向obj-m变量中设定的模块
执行make命令开始编译模块,生成hello.ko，执行make clean可清除编译产生的文件。
1、添加模块
|
1
|
insmod hello.ko |
2、查看模块
|
1
|
lsmod | grep hello |
lsmod命令实际上读取并分析/proc/modules文件，也可以cat /proc/modules文件
在模块所在目录下执行
modinfo hello.ko可以查看模块信息,如下所示
|
1
2
3
4
5
6
7
8
|
filename: hello.koalias: a simple moduledescription: A simple Moduleauthor: Mikcy Liulicense: GPLsrcversion: 875C95631F4F336BBD4216Cdepends: vermagic: 3.5.0-17-generic SMP mod_unload modversions 686 |
3、删除模块
|
1
|
rmmod hello |
模块加载函数
Linux内核模块加载函数一般以__init标识声明，典型的模块加载函数的形式如下：
|
1
2
3
4
|
static int __init initialization_function(void) { //初始化代码 } module_init(initialization_function); |
模块加载函数必须以“module_init(函数名)”的形式指定。它返回整形值，若初始化成功，应返回0。而在初始化失败时。应该返回错误编码。
在linux内核里，错误编码是一个负值，在<linux/errno.h>中定义，包含-ENODEV、-ENOMEM之类的符号值。返回相应的错误编码是种非常好的习惯，因为只有这样，用户程序才可以利用perror等方法把它们转换成有意义的错误信息字符串。
在linux2.6内核中，所有标识为__init的函数在连接的时候都会放在.init.text（这是module_init宏在目标代码中增加的一个特殊区段，用于说明内核初始化函数的所在位置）这个区段中，此外，所有的__init函数在区段.initcall.init中还保存着一份函数指针，在初始化时内核会通过这些函数指针调用这些__init函数，并在初始化完成后释放init区段（包括.init.text和.initcall.init等）。所以大家应注意不要在结束初始化后仍要使用的函数上使用这个标记。
模块卸载函数
Linux内核卸载模块函数一般以__exit标识声明，典型的模块卸载函数的形式如下：
|
1
2
3
4
|
static void __exit cleanup_function(void) { //释放代码 } module_exit(cleanup_function); |
模块卸载函数在模块卸载时被调用，不返回任何值，必须以”module_exit(函数名)”的形式来指定
与__init一样__exit也可以使对应函数在运行完成后自动回收内存。
一般来说，模块卸载函数完成与模块加载函数相反的功能：
如果模块加载函数注册了 XXX模块，则模块卸载函数应注销XXX。
若模块加载函数动体申请了内存，则模块卸载函数应释放该内存。
若模块加载函数申请了硬件资源，则模块卸载函数应释放这些硬件资源。
若模块加载函数开启了硬件，则模块卸载函数应关闭硬件。
内核时间管理
(1)内核中的时间概念
时间管理在linux内核中占有非常重要的作用。
相对于事件驱动而言，内核中有大量函数是基于时间驱动的。
有些函数是周期执行的，比如每10毫秒刷新一次屏幕；
有些函数是推后一定时间执行的，比如内核在500毫秒后执行某项任务。
要区分：
*绝对时间和相对时间
*周期性产生的事件和推迟执行的事件
周期性事件是由系统系统定时器驱动的
(2)HZ值
内核必须在硬件定时器的帮助下才能计算和管理时间。
定时器产生中断的频率称为节拍率(tick rate)。
在内核中指定了一个变量HZ，内核初始化的时候会根据这个值确定定时器的节拍率。
HZ定义在<asm/param.h>，在i386平台上，目前采用的HZ值是1000。
也就是时钟中断每秒发生1000次，周期为1毫秒。即：
#define HZ 1000
注意！HZ不是个固定不变的值，它是可以更改的，可以在内核源代码配置的时候输入。
不同的体系结构其HZ值是不一样的，比如arm就采用100。
如果在驱动中要使用系统的中断频率，直接使用HZ，而不要用100或1000
a.理想的HZ值
i386的HZ值一直采用100，直到2.5版后才改为1000。
提高节拍率意味着时钟中断产生的更加频繁，中断处理程序也会更频繁地执行。
带来的好处有：
*内核定时器能够以更高的频率和更高的准确度运行
*依赖定时器执行的系统调用，比如poll()和select()，运行的精度更高
*提高进程抢占的准确度
(缩短了调度延时，如果进程还剩2ms时间片，在10ms的调度周期下，进程会多运行8ms。
由于耽误了抢占，对于一些对时间要求严格的任务会产生影响)
坏处有：
*节拍率要高，系统负担越重。
中断处理程序将占用更多的处理器时间。
(3)jiffies
全局变量jiffies用于记录系统启动以来产生的节拍的总数。
启动时，jiffies初始化为0，此后每次时钟中断处理程序都会增加该变量的值。
这样，系统启动后的运行时间就是jiffies/HZ秒
jiffies定义于<linux/jiffies.h>中：
extern unsigned long volatile jiffies;
jiffies变量总是为unsigned long型。
因此在32位体系结构上是32位，而在64位体系上是64位。
对于32位的jiffies，如果HZ为1000，49.7天后会溢出。
虽然溢出的情况不常见，但程序在检测超时时仍然可能因为回绕而导致错误。
linux提供了4个宏来比较节拍计数，它们能正确地处理节拍计数回绕。
|
1
2
3
4
5
6
|
#include <linux/jiffies.h> #define time_after(unknown, known) // unknow > known #define time_before(unknown, known) // unknow < known #define time_after_eq(unknown, known) // unknow >= known #define time_before_eq(unknown, known) // unknow <= known |
unknown通常是指jiffies，known是需要对比的值(常常是一个jiffies加减后计算出的相对值)
例：
|
1
2
3
4
5
6
|
unsigned long timeout = jiffies + HZ/2; /* 0.5秒后超时 */... if(time_before(jiffies, timeout)){ /* 没有超时，很好 */}else{ /* 超时了，发生错误 */ |
time_before可以理解为如果在超时(timeout)之前(before)完成
*系统中还声明了一个64位的值jiffies_64，在64位系统中jiffies_64和jiffies是一个值。
可以通过get_jiffies_64()获得这个值。
*使用
|
1
2
|
u64 j2; j2 = get_jiffies_64(); |
(4)获得当前时间
驱动程序中一般不需要知道墙钟时间(也就是年月日的时间)。但驱动可能需要处理绝对时间。
为此，内核提供了两个结构体，都定义在<linux/time.h>：
a.
|
1
2
3
4
|
struct timeval { time_t tv_sec; /* seconds */ suseconds_t tv_usec; /* microseconds */}; |
较老，但很流行。采用秒和毫秒值，保存了1970年1月1日0点以来的秒数
b.
|
1
2
3
4
|
struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */}; |
较新，采用秒和纳秒值保存时间。
c.do_gettimeofday()
该函数用通常的秒或微秒来填充一个指向struct timeval的指针变量，原型如下：
|
1
2
3
|
#include <linux/time.h> void do_gettimeofday(struct timeval *tv); |
d.current_kernel_time()
该函数可用于获得timespec
|
1
2
|
#include <linux/time.h> struct timespec current_kernel_time(void); |
确定时间的延迟执行
设备驱动程序经常需要将某些特定代码延迟一段时间后执行，通常是为了让硬件能完成某些任务。
长于定时器周期(也称为时钟嘀嗒)的延迟可以通过使用系统时钟完成，而非常短的延时则通过软件循环的方式完成
(1)短延时
对于那些最多几十个毫秒的延迟，无法借助系统定时器。
系统通过软件循环提供了下面的延迟函数：
|
1
2
3
4
5
|
#include <linux/delay.h> /* 实际在<asm/delay.h> */void ndelay(unsigned long nsecs); /*延迟纳秒 */void udelay(unsigned long usecs); /*延迟微秒 */void mdelay(unsigned long msecs); /*延迟毫秒 */ |
这三个延迟函数均是忙等待函数，在延迟过程中无法运行其他任务。
(2)长延时
a.在延迟到期前让出处理器
|
1
2
|
while(time_before(jiffies, j1)) schedule(); |
在等待期间可以让出处理器，但系统无法进入空闲模式(因为这个进程始终在进行调度)，不利于省电。
b.超时函数
|
1
2
|
#include <linux/sched.h> signed long schedule_timeout(signed long timeout); |
使用方式：
|
1
2
|
set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(2*HZ); /* 睡2秒 */ |
进程经过2秒后会被唤醒。如果不希望被用户空间打断，可以将进程状态设置为TASK_UNINTERRUPTIBLE。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
#include <linux/init.h> #include <linux/module.h> #include <linux/time.h> #include <linux/sched.h> #include <linux/delay.h> static int __init test_init(void) { set_current_state(TASK_INTERRUPTIBLE); schedule_timeout(5 * HZ); printk(KERN_INFO "Hello Micky
"); return 0; } static void __exit test_exit(void) { } module_init(test_init); module_exit(test_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Micky Liu"); MODULE_DESCRIPTION("Test for delay"); |
(3)等待队列
使用等待队列也可以实现长延迟。
在延迟期间，当前进程在等待队列中睡眠。
进程在睡眠时，需要根据所等待的事件链接到某一个等待队列。
a.声明等待队列
等待队列实际上就是一个进程链表，链表中包含了等待某个特定事件的所有进程。
|
1
2
3
4
5
6
|
#include <linux/wait.h> struct __wait_queue_head { spinlock_t lock; struct list_head task_list; }; typedef struct __wait_queue_head wait_queue_head_t; |
要想把进程加入等待队列，驱动首先要在模块中声明一个等待队列头，并将它初始化。
静态初始化
|
1
|
DECLARE_WAIT_QUEUE_HEAD(name); |
动态初始化
|
1
2
|
wait_queue_head_t my_queue; init_waitqueue_head(&my_queue); |
b.等待函数
进程通过调用下面函数可以在某个等待队列中休眠固定的时间：
|
1
2
3
|
#include <linux/wait.h> long wait_event_timeout(wait_queue_head_t q,condition, long timeout); long wait_event_interruptible_timeout(wait_queue_head_t q, condition, long timeout); |
调用这两个函数后，进程会在给定的等待队列q上休眠，但会在超时(timeout)到期时返回。
如果超时到期，则返回0，如果进程被其他事件唤醒，则返回剩余的时间数。
如果没有等待条件，则将condition设为0
使用方式：
|
1
2
3
4
|
wait_queue_head_t wait; init_waitqueue_head(&wait); wait_event_interruptible_timeout(wait, 0, 2*HZ); /*当前进程在等待队列wait中睡2秒 */ |
(4)内核定时器
还有一种将任务延迟执行的方法是采用内核定时器。
与前面几种延迟方法不同，内核定时器并不会阻塞当前进程，
启动一个内核定时器只是声明了要在未来的某个时刻执行一项任务，当前进程仍然继续执行。
不要用定时器完成硬实时任务
定时器由结构timer_list表示，定义在<linux/timer.h>
|
1
2
3
4
5
6
7
|
struct timer_list{ struct list_head entry; /* 定时器链表 */ unsigned long expires; /* 以jiffies为单位的定时值 */ spinlock_t lock; void(*function)(unsigned long); /* 定时器处理函数 */ unsigned long data; /* 传给定时器处理函数的参数 */} |
内核在<linux/timer.h>中提供了一系列管理定时器的接口。
a.创建定时器
|
1
|
struct timer_list my_timer; |
b.初始化定时器
|
1
2
3
4
5
|
init_timer(&my_timer); /* 填充数据结构 */my_timer.expires = jiffies + delay; my_timer.data = 0; my_timer.function = my_function; /*定时器到期时调用的函数*/ |
c.定时器的执行函数
超时处理函数的原型如下：
|
1
|
void my_timer_function(unsigned long data); |
可以利用data参数用一个处理函数处理多个定时器。可以将data设为0
d.激活定时器
|
1
|
add_timer(&my_timer); |
定时器一旦激活就开始运行。
e.更改已激活的定时器的超时时间
|
1
|
mod_timer(&my_timer, jiffies+ney_delay); |
可以用于那些已经初始化但还没激活的定时器，
如果调用时定时器未被激活则返回0，否则返回1。
一旦mod_timer返回，定时器将被激活。
f.删除定时器
|
1
|
del_timer(&my_timer); |
被激活或未被激活的定时器都可以使用，如果调用时定时器未被激活则返回0，否则返回1。
不需要为已经超时的定时器调用，它们被自动删除
g.同步删除
|
1
|
del_time_sync(&my_timer); |
在smp系统中，确保返回时，所有的定时器处理函数都退出。不能在中断上下文使用。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
#include <linux/init.h> #include <linux/module.h> #include <linux/time.h> #include <linux/sched.h> #include <linux/delay.h> #include <linux/timer.h> struct timer_list my_timer; static void timer_handler(unsigned long arg) { printk(KERN_INFO "%s %d Hello Micky! arg=%lu
",__func__, __LINE__, arg ); } static int __init test_init(void) { init_timer(&my_timer); my_timer.expires = jiffies + 5 * HZ; my_timer.function = timer_handler; my_timer.data = 10; add_timer(&my_timer); return 0; } static void __exit test_exit(void) { del_timer(&my_timer); } module_init(test_init); module_exit(test_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Micky Liu"); MODULE_DESCRIPTION("Test for timer"); #include <linux/init.h> #include <linux/module.h> #include <linux/time.h> #include <linux/sched.h> #include <linux/delay.h> #include <linux/timer.h> struct timer_list my_timer; static void timer_handler(unsigned long arg) { printk(KERN_INFO "%s %d Hello Micky! arg=%lu
",__func__, __LINE__, arg ); } static int __init test_init(void) { init_timer(&my_timer); //my_timer.expires = jiffies + 5 * HZ; my_timer.function = timer_handler; my_timer.data = 10; //add_timer(&my_timer); mod_timer(&my_timer, jiffies + 5 * HZ); return 0; } static void __exit test_exit(void) { del_timer(&my_timer); } module_init(test_init); module_exit(test_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Micky Liu"); MODULE_DESCRIPTION("Test for timer"); |
不确定时间的延迟执行
(1)什么是不确定时间的延迟
前面介绍的是确定时间的延迟执行，但在写驱动的过程中经常遇到这种情况：
用户空间程序调用read函数从设备读数据，但设备中当前没有产生数据。
此时，驱动的read函数默认的操作是进入休眠，一直等待到设备中有了数据为止。
这种等待就是不定时的延迟，通常采用休眠机制来实现。
(2)休眠
休眠是基于等待队列实现的，前面我们已经介绍过wait_event系列函数，
但现在我们将不会有确定的休眠时间。
当进程被置入休眠时，会被标记为特殊状态并从调度器的运行队列中移走。
直到某些事件发生后，如设备接收到数据，则将进程重新设为运行态并进入运行队列进行调度。
休眠函数的头文件是<linux/wait.h>，具体的实现函数在kernel/wait.c中。
a.休眠的规则
*永远不要在原子上下文中休眠
*当被唤醒时，我们无法知道睡眠了多少时间，也不知道醒来后是否获得了我们需要的资源
*除非知道有其他进程会在其他地方唤醒我们，否则进程不能休眠
b.等待队列的初始化
见前文
c.休眠函数
linux最简单的睡眠方式为wait_event宏。该宏在实现休眠的同时，检查进程等待的条件。
A.
|
1
2
3
4
|
void wait_event( wait_queue_head_t q, int condition); |
B.
|
1
|
int wait_event_interruptible(wait_queue_head_t q, int condition); |
q: 是等待队列头，注意是采用值传递。
condition: 任意一个布尔表达式，在条件为真之前，进程会保持休眠。
注意！进程需要通过唤醒函数才可能被唤醒，此时需要检测条件。
如果条件满足，则被唤醒的进程真正醒来；
如果条件不满足，则进程继续睡眠。
d.唤醒函数
当我们的进程睡眠后，需要由其他的某个执行线程(可能是另一个进程或中断处理例程)唤醒。
唤醒函数：
#include <linux/wait.h>
1.
|
1
2
|
void wake_up( wait_queue_head_t *queue); |
2.
|
1
2
|
void wake_up_interruptible( wait_queue_head_t *queue); |
wake_up会唤醒等待在给定queue上的所有进程。
而wake_up_interruptible唤醒那些执行可中断休眠的进程。
实践中，约定做法是在使用wait_event时使用wake_up，而使用wait_event_interruptible时使用wake_up_interruptible。