阻塞和非阻塞IO是Linux驱动开发里面很常见的两种设备访问模式,在编写驱动的时候一定要考虑到阻塞和非阻塞。本章就来学习一下阻塞和非阻塞IO,以及如何在驱动程序中处理阻塞与非阻塞,如何在驱动程序使用等待队列和poll机制。
这里的“IO”并不是学习单片机的时候所说的“GPIO”(也就是引脚)。这里的IO指的是Input/Output,也就是输入/输出,是应用程序对驱动设备的输入/输出操作。当应用程序对设备驱动进行操作的时候,如果不能获取到设备资源,那么阻塞式IO就会将应用程序对应的线程挂起,直到设备资源可以获取为止。对于非阻塞IO,应用程序对应的线程不会挂起,它要么一直轮询等待,直到设备资源可以使用,要么就直接放弃。阻塞式IO如下图所示:
上图中应用程序调用read函数从设备中读取数据,当设备不可用或数据未准备好的时候就会进入到休眠态。等设备可用的时候就会从休眠态唤醒,然后从设备中读取数据返回给应用程序。
非阻塞IO如下图所示:
从上图可以看出,应用程序使用非阻塞访问方式从设备读取数据,当设备不可用或数据未准备好的时候会立即向内核返回一个错误码,表示数据读取失败。应用程序会再次重新读取数据,这样一直往复循环,直到数据读取成功。
应用程序可以使用如下所示示例代码来实现阻塞访问:
示例代码32.1.1.1 应用程序阻塞读取数据
1 int fd;
2 int data = 0;
3
4 fd = open("/dev/xxx_dev", O_RDWR); /* 阻塞方式打开 */
5 ret = read(fd, &data, sizeof(data)); /* 读取数据 */
从示例代码32.1.1.1可以看出,对于设备驱动文件的默认读取方式就是阻塞式的,所以前面所有的例程测试APP都是采用阻塞IO。
如果应用程序要采用非阻塞的方式来访问驱动设备文件,可以使用如下所示代码:
示例代码32.1.1.2 应用程序非阻塞读取数据
1 int fd;
2 int data = 0;
3
4 fd = open("/dev/xxx_dev", O_RDWR | O_NONBLOCK); /* 非阻塞方式打开 */
5 ret = read(fd, &data, sizeof(data)); /* 读取数据 */
第4行使用open函数打开“/dev/xxx_dev”设备文件的时候添加了参数O_NONBLOCK表示以非阻塞方式打开设备,这样从设备中读取数据的时候就是非阻塞方式的了。
阻塞访问最大的好处就是当设备文件不可操作的时候进程可以进入休眠态,这样可以将CPU资源让出来。但是,当设备文件可以操作的时候就必须唤醒进程,一般在中断函数里面完成唤醒工作。Linux内核提供了等待队列(wait queue)来实现阻塞进程的唤醒工作,如果要在驱动中使用等待队列,必须创建并初始化一个等待队列头,等待队列头使用结构体wait_queue_head表示,wait_queue_head结构体定义在文件include/linux/wait.h中,结构体内容如下所示:
有些资料里面用wait_queue_head_t表示等待队列头,从38行可以看出,wait_queue_head_t是wait_queue_head的别名,这么做的目的是为了兼容老版本代码。最新版本的系统都用wait_queue_head表示等待队列头,如果代码要考虑移植到老版本linux内核中,那么最好使用wait_queue_head_t表示等待队列头。
定义好等待队列头以后需要初始化,使用init_waitqueue_head函数初始化等待队列头,函
数原型如下:
void init_waitqueue_head(struct wait_queue_head *wq_head)
参数wq_head就是要初始化的等待队列头。也可以使用宏DECLARE_WAIT_QUEUE_HEAD来一次性完成等待队列头的定义的初始化。
等待队列头就是一个等待队列的头部,每个访问设备的进程都是一个队列项,当设备不可用的时候就要将这些进程对应的队列项添加到等待队列里面。在以前的linux版本中使用结构体wait_queue_t表示等待队列项,在5.4版本的linux内核中已经删除了wait_queue_t,取而代之的是wait_queue_entry结构体,wait_queue_entry结构体内容如下:
使用宏DECLARE_WAITQUEUE定义并初始化一个等待队列项,宏的内容如下:
DECLARE_WAITQUEUE(name, tsk)
name就是等待队列项的名字,tsk表示这个等待队列项属于哪个任务(进程),一般设置为current,在Linux内核中current相当于一个全局变量,表示当前进程。因此宏DECLARE_WAITQUEUE就是给当前正在运行的进程创建并初始化了一个等待队列项。
当设备不可访问的时候就需要将进程对应的等待队列项添加到前面创建的等待队列头中,只有添加到等待队列头中以后进程才能进入休眠态。当设备可以访问以后再将进程对应的等待队列项从等待队列头中移除即可,等待队列项添加API函数如下:
void add_wait_queue(struct wait_queue_head *wq_head,
struct wait_queue_entry *wq_entry)
函数参数和返回值含义如下:
等待队列项移除API函数如下:
void remove_wait_queue(struct wait_queue_head *wq_head,
struct wait_queue_entry *wq_entry)
函数参数和返回值含义如下:
当设备可以使用的时候就要唤醒进入休眠态的进程,唤醒可以使用如下两个函数:
void wake_up(struct wait_queue_head *wq_head)
void wake_up_interruptible(struct wait_queue_head *wq_head)
参数wq_head就是要唤醒的等待队列头,这两个函数会将这个等待队列头中的所有进程都唤醒。 wake_up函数可以唤醒处于TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE状态的进程,而wake_up_interruptible函数只能唤醒处于TASK_INTERRUPTIBLE状态的进程。
除了主动唤醒以外,也可以设置等待队列等待某个事件,当这个事件满足以后就自动唤醒等待队列中的进程,和等待事件有关的API函数如下图所示:
如果用户应用程序以非阻塞的方式访问设备,设备驱动程序就要提供非阻塞的处理方式,也就是轮询。poll、epoll和select可以用于处理轮询,应用程序通过select、epoll或poll函数来查询设备是否可以操作,如果可以操作的话就从设备读取或者向设备写入数据。当应用程序调用select、epoll或poll函数的时候设备驱动程序中的poll函数就会执行,因此需要在设备驱动程序中编写poll函数。
select函数原型如下:
int select(int nfds,
fd_set *readfds,
fd_set *writefds,
fd_set *exceptfds,
struct timeval *timeout)
函数参数和返回值含义如下:
比如现在要从一个设备文件中读取数据,那么就可以定义一个fd_set变量,这个变量要传递给参数readfds。当定义好一个fd_set变量以后可以使用如下所示几个宏进行操作:
void FD_ZERO(fd_set *set)
void FD_SET(int fd, fd_set *set)
void FD_CLR(int fd, fd_set *set)
int FD_ISSET(int fd, fd_set *set)
FD_ZERO用于将fd_set变量的所有位都清零,FD_SET用于将fd_set变量的某个位置1,也就是向fd_set添加一个文件描述符,参数fd就是要加入的文件描述符。FD_CLR用户将fd_set变量的某个位清零,也就是将一个文件描述符从fd_set中删除,参数fd就是要删除的文件描述符。FD_ISSET用于测试一个文件是否属于某个集合,参数fd就是要判断的文件描述符。
struct timeval
{
long tv_sec; /* 秒 */
long tv_usec; /* 微妙 */
};
当timeout为 NULL的时候就表示无限期的等待。
使用select函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示:
示例代码32.1.3.1 select函数非阻塞读访问示例
1 void main(void)
2 {
3 int ret, fd; /* 要监视的文件描述符 */
4 fd_set readfds; /* 读操作文件描述符集 */
5 struct timeval timeout; /* 超时结构体 */
6
7 fd = open("dev_xxx", O_RDWR | O_NONBLOCK); /* 非阻塞式访问 */
8
9 FD_ZERO(&readfds); /* 清除readfds */
10 FD_SET(fd, &readfds); /* 将fd添加到readfds里面 */
11
12 /* 构造超时时间 */
13 timeout.tv_sec = 0;
14 timeout.tv_usec = 500000; /* 500ms */
15
16 ret = select(fd + 1, &readfds, NULL, NULL, &timeout);
17 switch (ret) {
18 case 0: /* 超时 */
19 printf("timeout!\r\n");
20 break;
21 case -1: /* 错误 */
22 printf("error!\r\n");
23 break;
24 default: /* 可以读取数据 */
25 if(FD_ISSET(fd, &readfds)) { /* 判断是否为fd文件描述符 */
26 /* 使用read函数读取数据 */
27 }
28 break;
29 }
30 }
在单个线程中,select函数能够监视的文件描述符数量有最大的限制,一般为1024,可以修改内核将监视的文件描述符数量改大,但是这样会降低效率!这个时候就可以使用poll函数,poll函数本质上和select没有太大的差别,但是poll函数没有最大文件描述符限制,Linux应用程序中poll函数原型如下所示:
int poll(struct pollfd *fds,
nfds_t nfds,
int timeout)
函数参数和返回值含义如下:
使用poll函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示:
示例代码32.1.3.2 poll函数读非阻塞访问示例
1 void main(void)
2 {
3 int ret;
4 int fd; /* 要监视的文件描述符 */
5 struct pollfd fds;
6
7 fd = open(filename, O_RDWR | O_NONBLOCK); /* 非阻塞式访问 */
8
9 /* 构造结构体 */
10 fds.fd = fd;
11 fds.events = POLLIN; /* 监视数据是否可以读取 */
12
13 ret = poll(&fds, 1, 500); /* 轮询文件是否可操作,超时500ms */
14 if (ret) { /* 数据有效 */
15 ......
16 /* 读取数据 */
17 ......
18 } else if (ret == 0) { /* 超时 */
19 ......
20 } else if (ret < 0) { /* 错误 */
21 ......
22 }
23 }
传统的selcet和poll函数都会随着所监听的fd数量的增加,出现效率低下的问题,而且poll函数每次必须遍历所有的描述符来检查就绪的描述符,这个过程很浪费时间。为此,epoll应运而生,epoll就是为处理大并发而准备的,一般常常在网络编程中使用 epoll函数。应用程序需要先使用epoll_create函数创建一个epoll句柄,epoll_create函数原型如下:
int epoll_create(int size)
函数参数和返回值含义如下:
epoll句柄创建成功以后使用epoll_ctl函数向其中添加要监视的文件描述符以及监视的事件,epoll_ctl函数原型如下所示:
int epoll_ctl(int epfd,
int op,
int fd,
struct epoll_event *event)
函数参数和返回值含义如下:
struct epoll_event
{
uint32_t events; /* epoll事件 */
epoll_data_t data; /* 用户数据 */
};
结构体epoll_event的events成员变量表示要监视的事件,可选的事件如下所示:
上面这些事件可以进行“或”操作,也就是说可以设置监视多个事件。
一切都设置好以后应用程序就可以通过epoll_wait函数来等待事件的发生,类似select函数。epoll_wait函数原型如下所示:
int epoll_wait(int epfd,
struct epoll_event *events,
int maxevents,
int timeout)
函数参数和返回值含义如下:
epoll更多的是用在大规模的并发服务器上,因为在这种场合下select和poll并不适合。当涉及到的文件描述符(fd)比较少的时候就适合用selcet和poll,本章就使用sellect和poll这两个函数。
当应用程序调用select或poll函数来对驱动程序进行非阻塞访问的时候,驱动程序file_operations操作集中的poll函数就会执行。所以驱动程序的编写者需要提供对应的poll函数,poll函数原型如下所示:
unsigned int (*poll) (struct file *filp, struct poll_table_struct *wait)
函数参数和返回值含义如下:
void poll_wait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p)
参数wait_address是要添加到poll_table中的等待队列头,参数p就是poll_table,就是file_operations中poll函数的wait参数。
在上一篇笔记中的Linux中断实验中,直接在应用程序中通过read函数不断的读取按键状态,当按键有效的时候就打印出按键值。这种方法有个缺点,那就是keyirqApp这个测试应用程序拥有很高的CPU占用率,可以在开发板中加载上篇笔记中的驱动程序模块keyirq.ko,然后以后台运行模式打开keyirqApp这个测试软件,命令如下:
./keyirqApp /dev/keyirq & |
测试驱动是否正常工作,如果驱动工作正常的话输入“top”命令查看keyirqApp这个应用程序的CPU使用率,结果如下图所示:
从上图可以看出,keyirqApp这个应用程序的CPU使用率竟然高达50%,原因就在于是直接在while循环中通过read函数读取按键值,因此keyirqApp这个软件会一直运行,一直读取按键值,CPU使用率肯定就会很高。最好的方法就是在没有有效的按键事件发生的时候,keyirqApp这个应用程序应该处于休眠状态,当有按键事件发生以后keyirqApp这个应用程序才运行,打印出按键值,这样就会降低CPU使用率,本小节就使用阻塞IO来实现此能。
这个就是之前的按键原理图。
在之前Linux中断的基础上进行改写。
首先在key的设备结构体中,最后添加一个读等待队列头,是w,ait_queue_head_t类型的,命名为r_wait;同时,自旋锁的部分就可以删除了,改成用原子变量来实现保护,atomic_t status来表示按键状态并保护(阻塞IO需要等待队列,等待队列会会使线程休眠,所以不能自旋锁)。
在之后的定时处理函数key_timer_function中,把之前的自旋锁全部换成atomic_set来进行原子保护并设置按键状态,然后判断如果涉及按下或松开按键,就通过wake_up_interruptible唤醒等待队列,参数是&key.r_wait,这样之后的key_read就会在阻塞进程中接触阻塞。
之后的key_read函数,从设备中读取数据,这里通过wait_event_interruptible,判断是否有对应事件发生唤醒等待队列,这里的状态读取就需要使用atomic_read(&key.status)。之后读取数据并copy_to_user发送后,通过atomic_set重置状态为保持状态,进入等待队列。
最后再驱动入口函数mykey_init中,需要通过init_waitqueue_head初始化等待队列头,并把原来的自旋锁初始化,换成atomic_set来初始化按键状态。
这里直接把之前Linux中断实验的keyirqApp.c复制过来就可以了。
这里还是老样子,Makefile就用最开始写好的范本,然后把obj-m改成blockio.o就好,之后“make”一下就可以了。
可通过如下命令功能编译:
arm-none-linux-gnueabihf-gcc blockioApp.c -o blockioApp |
将上一小节编译出来blockio.ko和blockioApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载blockio.ko驱动模块:
depmod //第一次加载驱动的时候需要运行此命令 modprobe blockio.ko //加载驱动 |
驱动加载成功以后使用如下命令打开blockioApp这个测试APP,并且以后台模式运行:
./blockioApp /dev/key & |
此时,按下开发板的KEY0按键,可以得到如下图结果:
当按下KEY0按键以后blockioApp这个测试APP就会打印出按键状态。输入“top”命令查看blockioAPP这个应用APP的CPU使用率,如下图所示:
从上图可以看出,当在按键驱动程序里面加入阻塞访问以后,blockioApp这个应用程序的CPU使用率降低到了0%。这里的0%并不是说blockioApp这个应用程序不使用CPU了,只是因为使用率太小了,CPU使用率可能为0.000001%,但是上图是没有小数点显示的,因此就显示成了0%。
可以使用“kill”命令关闭后台运行的应用程序,比如关闭掉blockioApp这个后台运行的应用程序。首先输出“Ctrl+C”关闭top命令界面,进入到命令行模式。然后使用“ps”命令查看一下blockioApp这个应用程序的PID,之后使用“kill -9 PID”就可以关掉指定PID进程。
还是按键的原理图。
在之前添加了阻塞IO驱动的基础上,添加非阻塞IO代码。
在设备读取的key_read函数中,需要判断是否是非阻塞式读取,通过filp->f_flags & O_NONBLOCK来判断,如果是的话,就直接atomic_read来判断状态就可以了,不是就进入之前的阻塞IO代码。
由于是非阻塞,所以需要写一个key_poll的函数,就是file_operations驱动操作集中的poll函数,里面调用poll_wait将等待队列头添加到poll_table,然后通过atomic_read判断状态,有效就会返回POLLIN。
最后,在设备操作函数的file_operations的key_fops中,添加.poll = key_poll,添加操作函数。
这里的argc就只有2个参数;open的时候,还需要传入O_NONBLOCK来选择非阻塞IO;同时,open之后还需要FD_ZERO来将fd_set清零,并通过FD_SET来把当前fd加入。
之后通过死循环,然后调用select进行轮询,如果成功读取(通过FD_ISSET判断fd是否属于队列集),成功后通过read来读取按键值。
直接修改Makefile的obj-m为noblock.o,然后“make”就可以了。
输入如下命令即可:
arm-none-linux-gnueabihf-gcc noblockioApp.c -o noblockioApp |
将上一小节编译出来noblockio.ko和 noblockioApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载blockio.ko驱动模块:
depmod //第一次加载驱动的时候需要运行此命令 modprobe noblockio.ko //加载驱动 |
驱动加载成功以后使用如下命令打开noblockioApp这个测试APP,并且以后台模式运行:
./noblockioApp /dev/key & |
这里要关闭后台运行的noblockioApp,同样可以直接“kill”,通过“ps”查看PID然后“kill -9 PID”就可以了。
阻塞IO就是在读取数据的时候,如果设备不可用就会把线程挂起进入休眠,直到设备可用然后从驱动中读取。这里就需要在设备结构体中添加atomic_t的原子状态以及wait_queue_head_t的等待队列头;然后在定时处理函数中,通过atomic_set改变状态,同时通过wake_up_interruptible唤醒;在读取数据的read函数中,通过wait_event_interruptible加入唤醒事件,然后copy_to_user发送数据。最后驱动入口函数要加上init_waitqueue_head来初始化等待队列头。
非阻塞IO就是在read读取数据过程中,如果设备不可用,就会立即给内核返回错误码,表示读取失败,然后应用程序就会再次读取数据循环往复,直到读取到数据。这一部分,需要在read的读取函数中,通过filp->f_flags&O_NONBLOCK判断是否为非阻塞,然后一样通过atomic_read来判断状态;之后需要添加自定义的poll函数,其中通过poll_wait进行轮询等待,如果atomic_read读到状态变化就要返回POLLIN;最后要在file_operations中添加.poll,传入自己的poll函数。测试APP中,需要在O_NONBLOCK来open驱动设备之后,通过FD_ZERO和FD_SET读取设备,然后在for死循环中通过select开启轮询,通过FD_ISSET判断是否读取成功,成功后调用read读取数据。