Linux驱动开发八股文：工作队列（Workqueue）
📚 Linux 驱动开发笔记：工作队列 (Workqueue)
一、 核心定义
工作队列是 Linux 内核中断下半部（Bottom Half）的一种重要机制。它允许你将耗时的、需要等待资源或可能导致休眠的任务，从中断处理函数（ISR）中推迟到稍后的进程上下文中执行。
- 关键特性：运行于进程上下文，可以休眠。
- 执行主体：内核线程（如
kworker/0:2）。
二、 为什么需要工作队列？ (对比 Tasklet)
在内核中，中断下半部主要有两种选择，它们的区别在于“执行环境”：
| 特性 | Tasklet | 工作队列 (Workqueue) |
|---|---|---|
| 执行上下文 | 中断（软中断）上下文 | 进程上下文 |
| 能否休眠 | 绝不可以（会系统崩溃） | 可以（如使用msleep） |
| 访问用户空间 | 不可以 | 不可以（虽然在进程上下文，但没有用户页表） |
| 优先级 | 极高，仅次于硬中断 | 较低，由调度器决定 |
| 代表身份 | 借用当前进程的“皮” | 拥有独立的内核线程 (kworker) |
三、 工作队列的运作机制
- 提交任务：驱动在 ISR 中通过
schedule_work函数提交一个work_struct。 - 排队等待：该任务进入系统默认的工作队列链表。
- 唤醒线程：内核唤醒对应的内核线程（
kworker）。 - 执行任务：
kworker线程从链表中取出任务，调用你编写的处理函数。 - 结束/调度：处理函数完成后，
kworker线程继续处理下一个任务，或者进入睡眠。
四、 核心 API 与编程步骤
1. 定义工作结构体与处理函数
处理函数的参数是结构体本身，通常通过container_of获取私有数据。
struct work_struct my_work; void my_work_func(struct work_struct *work) { // 这里可以休眠！ // printk("current->comm: %s, pid: %d\n", current->comm, current->pid); }2. 初始化 (Init)
在probe函数中完成，将函数指针绑定到结构体。
// 动态初始化 INIT_WORK(&gpio_key->work, my_work_func); // 或者静态定义 // DECLARE_WORK(name, function);3. 调度 (Schedule)
在中断上半部（ISR）中调用，触发异步执行。
static irqreturn_t gpio_key_isr(int irq, void *dev_id) { schedule_work(&gpio_key->work); // 只是挂入队列，不阻塞 return IRQ_HANDLED; }五、 实验现象深度解析
根据实验日志：
[165328.733643] {WORK_FUNC:}the process is kworker/0:2, its pid is 1722
- 身份证明：
current->comm是kworker/0:2，证明了工作队列不再是“借用”别人的身份，而是由内核专属的“工人”线程在干活。 - PID 1722：这是一个真实的进程 ID。在 Linux 中，凡是有 PID 的都能被调度器控制，这就是它为什么可以休眠的根本原因。
- 时序关系：日志中
TASKLET总是先于WORK_FUNC打印。这是因为 Tasklet 优先级更高，在中断返回的瞬间执行；而 Workqueue 需要等待调度器切换到kworker线程，存在毫秒级的调度延迟。
六、 注意事项与避坑指南
- 顺序阻塞：默认的工作队列由同一个
kworker线程依序处理。如果你在一个 Work 函数里写了while(1)或休眠太久，会堵塞同一个队列里的其他工作。 - 重入性：如果在 Work 还没执行完时又发生了中断并
schedule_work，内核通常不会重复启动同一个 Work 实例，它会等待当前运行的结束后再决定是否再次触发。 - API 演进：4.x 以后内核引入了CMWQ (Concurrency Managed Workqueue)，它能更聪明地在多核之间分配任务，避免单个耗时任务卡死整个 CPU 的工作队列。
七、 总结：何时选择工作队列？
- 任务很重（如：读取 1MB 的 Flash 数据）。
- 需要等待（如：等待某个信号量、互斥锁）。
- 需要延时（如：逻辑要求按键按下后等待 100ms 再读取）。