别人的经验，我们的阶梯!
大家好，我是道哥，今天我为大伙儿解说的技术知识点是：【中断处理中的下半部分机制-工作队列】。
在刚开始介绍中断处理的时候，曾经贴出下面这张图：
图中描述了中断处理中的下半部分都有哪些机制，以及如何根据实际的业务场景、限制条件来进行选择。
可以看出：这些不同的实现之间，有些是重复的，或者是相互取代的关系。
也正因为此，它们之间的使用方式几乎是大同小异，至少是在API接口函数的使用方式上，从使用这的角度来看，都是非常类似的。
这篇文章，我们就通过实际的代码操作，来演示一下工作队列(workqueue)的使用方式。
工作队列是什么
工作队列是Linux操作系统中，进行中断下半部分处理的重要方式!
从名称上可以猜到：一个工作队列就好像业务层常用的消息队列一样，里面存放着很多的工作项等待着被处理。
工作队列中有两个重要的结构体：工作队列(workqueue_struct) 和 工作项(work_struct)：
在内核中，工作队列中的所有工作项，是通过链表串在一起的，并且等待着操作系统中的某个线程挨个取出来处理。
这些线程，可以是由驱动程序通过 kthread_create 创建的线程，也可以是由操作系统预先就创建好的线程。
这里就涉及到一个取舍的问题了。
如果我们的处理函数很简单，那么就没有必要创建一个单独的线程来处理了。
原因有二：
为了避免这种情况，于是操作系统就为我们预先创建好一些工作队列和内核线程。
我们只需要把需要处理的工作项，直接添加到这些预先创建好的工作队列中就可以了，它们就会被相应的内核线程取出来处理。
例如下面这些工作队列，就是内核默认创建的(include/linux/workqueue.h)：
以上这些默认工作队列的创建代码是(kernel/workqueue.c)：
此外，由于工作队列 system_wq 被使用的频率很高，于是内核就封装了一个简单的函数(schedule_work)给我们使用：
当然了，任何事情有利就有弊!
由于内核默认创建的工作队列，是被所有的驱动程序共享的。
如果所有的驱动程序都把等待处理的工作项委托给它们来处理，那么就会导致某个工作队列中过于拥挤。
根据先来后到的原则，工作队列中后加入的工作项，就可能因为前面工作项的处理函数执行的时间太长，从而导致时效性无法保证。
因此，这里存在一个系统平衡的问题。
关于工作队列的基本知识点就介绍到这里，下面来实际操作验证一下。
驱动程序
之前的几篇文章，在驱动程序中测试中断处理的操作流程都是一样的，因此这里就不在操作流程上进行赘述了。
这里直接给出驱动程序的全貌代码，然后查看 dmesg 的输出信息。
创建驱动程序源文件和 Makefile：
示例代码全貌
测试场景是：加载驱动模块之后，如果监测到键盘上的ESC键被按下，那么就往内核默认的工作队列system_wq中增加一个工作项，然后观察该工作项对应的处理函数是否被调用。
Makefile 文件
编译、测试
检查驱动模块是否加载成功：
再看一下 dmesg 的输出信息：
说明：驱动程序的初始化函数 myirq_init 被调用了，并且成功注册了 1 号中断的处理程序。
此时，按一下键盘上的 ESC 键。
操作系统在捕获到键盘中断之后，会依次调用此中断的所有中断处理程序，其中就包括我们注册的 myirq_handler 函数。
在这个函数中，当判断出是ESC按键时，就初始化一个工作项(把结构体 work_struct 类型的变量与一个处理函数绑定起来)，然后丢给操作系统预先创建好的工作队列(system_wq)去处理，如下所示：
因此，当相应的内核线程从这个工作队列(system_wq)中取出工作项(mywork)来处理的时候，函数 mywork_handler 就会被调用。
现在来看一下 dmesg 的输出信息：
可以看到：mywork_handler函数被正确调用了。
完美!
原文链接：
发表评论