【Linux驱动】休眠与唤醒 | POLL机制 | 异步通知 | 阻塞与非阻塞

🐱作者：一只大喵咪1201
🐱专栏：《Linux驱动》
🔥格言：你只管努力，剩下的交给时间！

🏓休眠与唤醒

在前面讲解按键驱动时，本喵提到过休眠唤醒的按键驱动方式：应用程序必须等待按键按下后，才会继续执行，否则则处于阻塞状态。

如上图所示应用层APP获取按键值的流程：

APP调用read系统调用读取按键数据。
APP进入内核态，通过文件系统中的sys_read调用驱动层的drv_read。
发现有数据则复制到用户空间并马上返回，如果没有数据则APP休眠，也就是阻塞不动。

驱动中没有数据时，APP在内核态执行到drv_read时会休眠。所谓休眠就是把自己的状态改为非RUNNING，这样内核的调度器就不会让该APP运行了。

如上图，当APP1因为没有按键数据而休眠时，内核会挑选出其他APP去运行，当按下按键后：

驱动程序中的中断服务程序被调用，它会记录数据，并唤醒APP1。
当APP1再次运行时，就会继续执行drv_read中剩下的代码，把数据复制回用户空间，然后返回用户空间。

所谓唤醒就是把APP的状态改为RUNNING，这样内核的调度器在合适的时间就会让它运行。

APP1的执行过程如红色实线所示，它被分成了两段：

红线所涉及的代码，都是APP1调用的，它都属于APP1的上下文。
按键的中断服务程序，不属于APP1的上下文，它属于中断的上下文。

🏸内核函数

休眠函数：

当按键的驱动程序drv_read中没有按键数据时，就需要我们在驱动程序中让当前进程/线程去休眠，此时就需要使用内核提供的一些休眠函数：

函数	说明
wait_event_interruptible(wq, condition)	休眠，直到condition为真，休眠期间是可以被信号打断的
wait_event(wq, condition)	休眠，直到condition为真，退出的唯一条件就是condition为真，信号也无法打断。
wait_event_interruptible_timeout(wq, condition, timeout)	休眠，直到condition为真或者超时，休眠期间可以被信号打断
wait_event_timeout(wq, condition, timeout)	休眠，直到condition为真或者超时，信号无法打断。

参数说明：

wq：waitqueue，等待队列。
- 休眠时除了把程序状态改为非RUNNING之外，还要把进程/进程放入wq中，以后中断服务程序要从wq中把它取出来唤醒。
condition：可以是变量，也可以是任何表达式，表示一直等待，直到condition为真。

唤醒函数：

在按键的中断服务函数中，需要去唤醒处于休眠状态的进程/线程，同样也通过内核提供的唤醒函数：

函数	说明
wake_up_interruptible(x)	唤醒 x 队列中状态为TASK_INTERRUPTIBLE的线程，只唤醒其中的一个线程
wake_up_interruptible_nr(x, nr)	唤醒 x 队列中状态为“TASK_INTERRUPTIBLE”的线程，只唤醒其中的 nr 个线程
wake_up_interruptible_all(x)	唤醒 x 队列中状态为“TASK_INTERRUPTIBLE”的线程，唤醒其中的所有线程
wake_up(x)	唤醒 x 队列中状态为“TASK_INTERRUPTIBLE ”或 “TASK_UNINTERRUPTIBLE”的线程，只唤醒其中的一个线程
wake_up_nr(x, nr)	唤醒 x 队列中状态为“TASK_INTERRUPTIBLE”或“TASK_UNINTERRUPTIBLE”的线程，只唤醒其中nr个线程
wake_up_all(x)	唤醒 x 队列中状态为“TASK_INTERRUPTIBLE”或“TASK_UNINTERRUPTIBLE”的线程，唤醒其中的所有线程

参数说明：

x：就是前面在休眠时存放非RUNNING状态的线程/进程的队列。
TASK_INTERRUPTIBLE：该状态的休眠线程是可以被信号中断休眠的。
TASK_UNINTERRUPTIBLE：该状态的休眠线程是不可以被信号中断休眠的。

🏸驱动框架及编程

如上图所示是休眠唤醒的驱动框架，根据该框架，我们需要做这几件事情：

初始化wq队列，使用DECLARE_WAIT_QUEUE_HEAD()宏函数实现。
在驱动层的drv_read中，调用wait_event_interruptible()函数：
- 它本身会判断event参数是否为FALSE，如果为FASLE表示无数据，会将自己放入wq等待队列并休眠。
- 当从wait_event_interruptible()函数返回后，会继续把数据复制回用户空间。
在中断服务程序中，设置event为TRUE，并且调用wake_up_interruptible唤醒正在队列中休眠的线程/进程。

编程：

下面是在之前本喵实现的按键中断程序的基础上实现休眠唤醒，设备树文件本喵就不再贴图了，有兴趣的小伙伴移步这里。

本喵这里为了防止按键数据丢失，使用环形缓冲区来记录按键数据：

如上图所示环形缓冲区以及操作的接口函数定义，包括判空，判满，写数据和读数据。

gpio_key_drv_read函数

当应用层使用系统调用read时，最终会调用到file_operations结构体中的read函数，也就是gpio_key_drv_read驱动层读取数据的函数。

如上图代码所示，先使用DECLARE_WAIT_QUEUE_HEAD宏函数初始化等待队列gpio_key_wait。

当调用到驱动层的gpio_key_drv_read函数后，使用wait_event_interruptible函数：

如果环形缓冲区是空的，说明没有数据，则将当前线程放入到等待队列中休眠。
如果环形缓冲区不是空的，说明有数据，则不将当前线程放入等待队列，而是直接调用获取环形缓冲区中的数据并且拷贝到用户空间中。

如果因为没有数据而处于休眠状态，则该线程就会阻塞到这里，当该线程被唤醒后，说明环形缓冲区中有数据了，则读取数据并且拷贝到用户空间中。

gpio_key_isr中断服务函数

如果线程因为没有按键数据而休眠了，那么只能在中断服务程序中将其唤醒：

如上图所示中断服务函数，当按键中断产生后，获取GPIO引脚的逻辑值，然后构造出按键值：

按键值key：低八位是GPIO引脚的逻辑值，其余位是描述引脚信息的整数。

再调用wake_up_interruptible从等待队列gpio_key_wait中唤醒因为没有读取到按键数据而休眠的线程。

在中断服务函数中向环形缓冲区中写入了按键数据，也就是意味着驱动程序drv_read中的event：!is_key_buf_empty()变成了TRUE，所以线程就被唤醒了。
由于gpio_key_wait是专门用来存放读取按键的线程的，所以目前该等待队列中只有一个线程，中断服务函数不会唤醒错误。

演示：

如上图应用层的button_test.c测试代码，在打开按键设备以后，在while死循环中使用read系统调用读取按键数据，如果读取到就打印出来：

如果没有按键数据，该进程会阻塞在read调用处，不会执行下去。
当有按键数据时，进程就会继续执行。

将驱动程序和测试程序上传到服务器进行编译，将得到的gpio_key_drv.ko和button_test拷贝到网络文件系统中供开发板使用，本喵这里就不演示具体的步骤了。

如上图所示，将按键驱动程序安装以后，再运行应用层的测试程序：

运行起来后，程序阻塞在read处，因为没有按键值。
按下开发板上的按键后，驱动程序打印出了按键的整数编号和逻辑值。
应用程序打印出了我们在驱动程序中构建后的按键值。

🏓POLL机制

休眠唤醒机制的致命缺陷在于，如果没有按键数据，进程/线程就会一直死等下去。而POLL机制就是为了解决这个问题的：

APP不知道驱动程序中是否有数据，可以先调用poll函数查询一下，poll函数可以传入超时时间。
APP进入内核态，调用到驱动程序的drv_poll函数，如果有数据的话立刻返回。
如果发现没有数据时就休眠一段时间。
- 当按下按键时，驱动程序的中断服务程序被调用，它会记录数据并且唤醒APP。
- 当超时时间到了之后，内核也会唤醒APP。
APP根据poll函数的返回值就可以知道是否有数据，如果有数据就调用read得到数据。

如上图所示poll机制执行的流程，分为9步：

APP使用open系统调用打开按键设备。
通过内核文件系统中sys_open函数调用file_operation结构体中的drv_open驱动函数来打开设备。

每一个设备，内核都会将其看成是一个文件，都会在内核中创建一个struct file结构体来描述这个设备，该结构体就位于内核的文件系统中。

APP调用poll系统调用后进入内核态。
内核文件系统中的sys_poll，会在死循环for中，先调用驱动程序的drv_poll来获取状态event。
- 在驱动程序drv_poll中，要把当前线程挂入到等待队列wq中，否则在唤醒的时候就找不到该线程了。
- 但是驱动程序drv_poll并不会让当前线程休眠。
返回的状态表示当前没有数据，那么内核文件系统就让该线程休眠一会儿。
线程休眠过程中，按下了按键，产生了按键中断，在中断服务函数中记录按键值，并且从wq等待队列中将线程唤醒。
线程被唤醒后处于内核文件系统中的for死循环中，所以还要再执行一次drv_poll驱动程序，获取按键数据的状态。
此时获取到的数据状态表示有按键数据，就会从返回到用户态，APP可以继续执行不再阻塞。
APP根据poll的返回值发现有按键数据，则调用read函数读取按键数据。

如果一直没有按键数据，也就是线程在休眠后一直没有被唤醒，此时的流程也是类似的，从第三步开始看：

APP调用poll系统调用后进入内核态。
导致驱动程序的drv_poll被调用。
假设当前没有数据，则休眠一会。
在休眠过程中，一直没有按下了按键，超时时间到了，内核把这个线程唤醒。
线程从休眠中被唤醒，继续执行for循环，再次调用drv_poll驱动程序获取数据状态。
此时获取到的数据状态仍然表示没有数据，但是超时时间已经到了，也只能从内核态返回用户态了。
APP根据poll的返回值发现没有按键数据，则不能调用read函数读取按键数据。

这个过程中有几点需要注意：

drv_poll要把线程挂入队列wq，但是并不是在drv_poll中进入休眠，而是在调用drv_poll之后休眠。

drv_poll驱动程序只做两件事情：

把线程放入到等待队列wq中，但是不休眠。
返回event事件状态，而不是返回事件值。

APP调用一次poll，有可能会导致drv_poll被调用两次：
- 进入内核文件系统的for循环中先调用一次获取状态。
- 被唤醒后(中断或者超时)执行for循环再调用一次，判断是数据到来还是超时，然后返回用户态。
APP要判断poll返回的原因：
- 有数据到来，还是超时。有数据到来才能调用read函数读取按键值。

🏸驱动编程

使用poll机制时，驱动程序的核心就是提供对应的drv_poll函数。在drv_poll函数中要做两件事：

把当前线程挂入等待队列wq，使用内核提供的函数poll_wait来实现：
- APP调用一次poll，可能导致drv_poll被调用2次，但是我们并不需要把当前线程挂入队列2次。
- 使用内核的函数poll_wait把线程挂入队列，如果线程已经在队列里了，它就不会再次挂入。
返回设备状态，APP调用poll函数时，有可能是查询有没有数据可以读，有可能是查询有没有空间可以写数据。
- 有数据可以读：(POLLIN | POLLRDNORM)，POLLRDNORM 等同于 POLLIN，为了兼容某些 APP 把它们一起返回。
- 有空间可以写：(POLLOUT | POLLWRNORM)，POLLWRNORM 等同于 POLLOUT ，为了兼容某些 APP 把它们一起返回。

APP 调用poll后，很有可能会休眠。在按键驱动的中断服务程序中，也要有唤醒操作，也是通过内核提供的wake_up_interruptible函数从等待队列中唤醒。

所以中断服务函数不用做任何改动，主要是要实现drv_poll驱动函数：

如上图所示代码，在file_operations结构体中增加poll成员，并用gpio_key_drv_poll初始化，在该函数中完成那两件事情：

将当前线程放入等待队列gpio_key_wait，和前面休眠唤醒的是一个队列，但是不进行休眠。
返回按键数据状态，根据环形缓冲区是否为空，决定返回0，还是(POLLOUT | POLLWRNORM)。

可以看到，poll机制的驱动程序就是这么简单，此时就实现了，比较复杂一点的是应用层的程序。

🏸应用编程

应用层poll系统调用的用法，自行查看man手册，或者移步本喵的文章poll，本喵这里就直接用了。

如上图所示代码，由于我们只检测一个按键，所以struct pollfd fds[1]只有一个元素即可，设置超时时间为5s。

将驱动设备使用open打开后，将得到的fd作为监测目标填充到struct pollfd结构体中，包括检测的事件是POLLIN，和驱动程序中的drv_poll相对应。

全部配置好后，使用poll获取按键数据的状态：

没有按键数据，程序则阻塞在poll处休眠一会儿，等待被唤醒。
被唤醒后：
- 如果是因为超时唤醒，则poll得到的数据状态就是0，则打印超时。
- 如果是因为数据到来唤醒，则poll得到是数据状态就是(POLLOUT | POLLWRNORM)，使用read读取按键数据，此时read必然不会阻塞。

演示：

最后将驱动程序和应用程序上传到服务器进行编译，并且将生成的gpio_key_drv.ko和button_test拷贝到网络文件系统中。

如上图所示，将驱动程序安装好以后，在开发板运行测试程序后：

drv_poll驱动程序先运行一次查看按键数据状态，发现没有数据以后休眠一会儿。
迟迟没有按键按下，被超时唤醒，打印timeout。
当按键数据按下后，被数据唤醒后，打印按键数据。

🏓异步通知

如果APP在读取按键数据的过程中不想休眠怎么办？使用异步通知，也就是当有了按键数据以后，驱动程序主动通知APP有数据了，此时APP去读取数据即可，平时APP可以干其他事情。

如上图所示使用异步通知的流程图。

使用open系统调用打开驱动，得到驱动的文件描述符fd。
使用signal系统调用为SIGIO信号注册信号处理函数func。
- 按键驱动程序发出的信号是SIGIO信号，表示有数据输入。
- APP收到SIGIO信号后，处理函数func就会被自动调用。
使用fcntl将当前进程的PID设置到内核文件系统中的struct file结构体中，方便后面驱动程序找到进程。
读取驱动程序文件的Flag。
设置Flag里面的FASYNC位为 1：
- 该Flag也是记录到内核文件系统的struct file结构体中，驱动程序通过struct file* filp指针可以获取该标志。
- 当FASYNC位发生变化时，内核文件系统就会调用驱动程序的drv_fasync函数。
drv_fasync是否调用是由FASYNC标志位决定的，应用层并没有相应的fasync函数。
在drv_fasync函数中，调用内核提供的faync_helper函数，它会根据FAYSNC的值决定是否设置button_async->fa_file=驱动文件filp：
- 驱动文件filp结构体里面含有之前设置的PID。
- on就代表是着FAYSNC位，它为1则设置button_async，它为0则不设置。
APP可以做其他事情。
按键按下后，产生按键中断，调用中断服务函数。
在中断服务函数中调用内核提供的kill_fasync函数，向APP发送信号：
- 如果button_async->fa_file非空，则从它指向的filp的结构体中取出进程的PID，向该线程发送SIGIO信号。
- 如果button_async->fa_file为空，则该函数什么都不做，不会发送任何信号。
在按键中断服务程序中发送SIGIO信号后，信号处理函数func被调用。
在func中使用read系统调用读取按键数据。
最终会调用驱动层中的drv_read读取按键数据，此时一定是有数据的，并不会休眠。

在整个流程中可以看到，FASYNC的变化是为了启动drv_fasync，而真正做事情的是fasync_helper函数。

🏸驱动编程

使用异步通知时，驱动程序的核心有两步：

提供对应的drv_fasync函数。
并在合适的时机发信号，这一点在按键中断服务程序中完成。

如上图所示，创建一个struct fasync_struct*类型的全局指针变量button_fasync，该变量专门用来根据进程PID找到对应的进程的。

在file_operations结构体中增加成员fasync，并且使用gpio_key_drv_fasync初始化，在该函数中，只需要调用fasync_helper函数即可完成异步通知的记录工作。

如上图所示，在按键的中断服务函数中，通过内核提供的kill_fasync函数，向button_fasync中PID代表的线程发送SIGIO信号。

🏸应用编程

异步通知比较复杂的部分是在应用层的测试函数中：

如上图所示代码，首先定义一个信号处理函数sig_func函数，当该进程接收到信号后就调用该函数，此时一定是有按键数据的，所以直接调用read读取按键数据即可。

在main函数中，使用signal系统调用为SIGIO信号注册处理函数sig_func，当按键按下后，驱动程序就会发出SIGIO信号，处理函数就会被调用。

但是驱动程序怎么知道要将SIGIO信号发给哪个进程呢？此时就需要使用fcntl系统调用，将当前进程的PID和异步通知标志位FASYCN设置到内核文件系统的struct file结构体中。

此时由于FASYCN发发生了变动，触发了驱动层中的drv_fasync被调用，从而导致fasync_helper被调用。

此时异步通知就设置完毕了，APP就可以在while循环中干其他事情了，根本不用关心按键，因为按键会通过信号主动通知APP。

演示：

编译等过程本喵就不啰嗦了，直接演示：

如上图所示，运行测试程序后：

没有按键数据，APP在处理其他事情，打印I am A Big Miaomi字符串。
按键按下后，在信号处理函数中读取按键数据并且打印出来。

🏓阻塞与非阻塞

所谓阻塞，就是等待某件事情发生。比如调用read读取按键时，如果没有按键数据则read函数不会返回，它会让线程休眠等待。

此时的休眠是我们在驱动程序中通过内核提供的wait_event_xxx函数实现的。

能不能让read函数既能工作于阻塞方式，也可以工作于非阻塞方式？可以！

在APP中使用open函数时，可以传入O_NONBLOCK，就表示要使用非阻塞方式读取数据。默认情况是阻塞方式读取。
在APP中open一个文件之后，也可以通过fcntl系统调用修改为阻塞或非阻塞读取数据。

对于字符设备文件，O_NONBLOCK起作用的前提是驱动程序针对O_NONBLOCK做了处理。

🏸应用编程

这里本喵先来实现应用层编程：

如上图所示代码，它分为如下几步：

在使用open打开驱动设备时，传入O_NONBLOCK标志，使用非阻塞访问的方式打开。
然后不管有没有按键数据，使用非阻塞方式读取十次按键数据：
- 有按键数据则返回按键数据，并且打印。
- 没有按键数据则直接返回，并且打印-1。
使用fcntl将驱动设备设置为阻塞访问方式。
在while死循环中，使用read阻塞读取按键数据：
- 有按键数据则返回按键数据，并且打印。
- 没有按键数据则阻塞不动，不会打印内容。

🏸驱动编程

如上图代码所示，需要在驱动层的drv_read中作一些改动：

因为非阻塞方式在应用层设置的，并且O_NONBLOCK标志设置到内核文件系统的struct file结构体中的。
所以在drv_read驱动程序中，如果是非阻塞方式，并且没有按键数据，则不阻塞直接返回-EAGAIN。
如果是非阻塞方式，且有按键数据，则并不会将当前线程放入到等待队列中，而是返回按键数据。

此时驱动程序就支持阻塞和非阻塞两种访问方式了。

演示：

如上图所示，在开发板上运行起测试程序以后：

先非阻塞读取按键数据十次，由于此时没有按键数据，所以返回的都是-1。
然后开始阻塞读取按键数据，有按键数据时打印，没有按键数据时阻塞不动。

可以看到，我们在驱动程序中，这几种读取按键的方式都提供了。
应用层可以使用任意一种，我们不能指定应用层使用哪种方式。
驱动开发的原则只提供能力，不提供策略。

🏓定时器

所谓定时器，就是闹钟，时间到后就要做某些事。有两个要素：时间、做事，换成程序员的话就是：超时时间、函数。

本喵这里讲解的定时器是软件定时器，它依赖系统的滴答定时器。在内核中使用定时器比较简单，涉及到一些内核提供的函数：

函数	说明
setup_timer(timer, fn, data)	设置定时器，主要是初始化 timer_list 结构体，设置其中的函数、超时事件等参数。
void add_timer(struct timer_list *timer)	向内核添加定时器。
int mod_timer(struct timer_list *timer, unsigned long expires)	修改定时器的超时时间
int del_timer(struct timer_list *timer)	删除定时器。

当超时时间到达，内核就会调用这个超时函数： timer->function(timer->data)。

编译内核时，可以在内核源码根目录下用ls -a看到一个隐藏文件，它就是内核配置文件。打开后可以看到CONFIG_HZ=100，它表示内核每秒中会发生 100 次系统滴答中断(tick)。

每发生一次 tick 中断，全局变量jiffies就会累加1，定时器的时间就是基于 jiffies的，我们修改超时时间时，一般使用这2种方法：

在add_timer之前，直接修改：
- timer.expires = jiffies + xxx; // xxx 表示多少个滴答后超时，也就是 xxx*10ms
- timer.expires = jiffies + 2*HZ; // HZ 等于 CONFIG_HZ，2*HZ 就相当于 2 秒
在add_timer之后，使用mod_timer修改：
- mod_timer(&timer, jiffies + xxx); // xxx 表示多少个滴答后超时，也就是 xxx*10ms
- mod_timer(&timer, jiffies + 2*HZ); // HZ 等于 CONFIG_HZ，2*HZ 就相当于 2 秒