字符设备驱动poll机制实现非阻塞读写

深入字符设备驱动的`poll`机制：如何实现高效非阻塞 I/O

你有没有遇到过这样的场景？一个嵌入式系统需要同时监听多个传感器的数据，比如温湿度、加速度计和串口 GPS。如果用传统的轮询方式去读每个设备，CPU 占用率飙升到 80% 以上，而真正有效的数据却寥寥无几。更糟的是，一旦某个设备响应慢一点，整个程序就像卡住了一样。

这正是我在做工业采集网关时踩过的坑。

后来我意识到，问题不在于硬件性能不够强，而在于 I/O 模型选错了——我们用了“主动查”，而不是“等通知”。解决这个问题的关键，就是 Linux 内核提供的poll机制。

今天，我们就从实战角度出发，深入剖析字符设备驱动中poll的实现原理，看看它是如何让设备驱动从“被动查询”转向“事件驱动”的，以及为什么它是构建高并发、低延迟系统的基石。

什么是`poll`？它解决了什么问题？

在 Linux 中，一切皆文件。字符设备也不例外。用户空间通过open("/dev/mychar", ...)打开设备后，就可以像操作普通文件一样调用read()和write()。

但问题是：什么时候能读？什么时候能写？

如果直接调用read()，而设备还没准备好数据，进程就会被挂起（阻塞），直到有数据到来。
如果使用O_NONBLOCK标志打开设备，read()会立即返回-EAGAIN，你需要不断重试——这就是所谓的“忙等待”，白白浪费 CPU 资源。

那有没有一种方法，既能避免阻塞，又能避免空转呢？

答案是：poll。

poll允许应用程序一次性监控多个文件描述符的状态变化。它不会立刻返回，而是进入休眠，直到至少有一个设备就绪或超时为止。这种“状态可读时再唤醒”的设计，完美平衡了实时性与资源消耗。

更重要的是，这个能力不是凭空来的——它依赖于设备驱动中的.poll回调函数。也就是说，能不能支持高效的非阻塞 I/O，关键看你的驱动写得对不对。

`poll`是怎么工作的？一张图说清楚

想象一下你在等快递：

忙等待 = 每隔 5 分钟跑下楼看一次有没有送到；
阻塞读 = 坐在家里干等，别的事都不能做；
poll= 你告诉物业：“快递到了叫我一声。”然后安心工作，等电话响了再去拿。

在内核层面，这套“通知机制”是靠等待队列（wait queue）实现的。

当用户调用poll(fd, ...)时，内核会执行以下流程：

调用该设备的.poll函数；
驱动将当前进程登记到自己的等待队列中；
驱动检查自身状态（如接收缓冲区是否有数据）；
如果没有就绪事件且未超时，进程睡眠；
当硬件中断到来，数据写入缓冲区，驱动调用wake_up_interruptible()；
睡眠的进程被唤醒，重新检查状态并返回；
用户空间得知“现在可以安全读取”，于是调用read()。

整个过程的核心在于两个动作：
-注册监听：poll_wait()
-触发唤醒：wake_up_interruptible()

缺一不可。

如何在字符设备驱动中实现`.poll`接口？

下面是一个典型的.poll回调函数实现：

static unsigned int mychar_poll(struct file *filp, poll_table *wait) { unsigned int mask = 0; // 关键一步：将当前 poll 操作加入等待队列 poll_wait(filp, &dev_waitq, wait); // 判断是否可读：接收缓冲区中有数据？ if (data_len > 0) { mask |= POLLIN | POLLRDNORM; // 表示“可读” } // 判断是否可写：发送缓冲区未满？ if (data_len < buffer_size) { mask |= POLLOUT | POLLWRNORM; // 表示“可写” } return mask; }

这段代码的关键点解析：

✅`poll_wait()`并不会让进程休眠！

很多人误以为poll_wait()是“等待”的意思，其实不然。它的作用只是把当前进程关注的等待队列注册到内核的监控表中。真正的休眠是由sys_poll()内部完成的。

你可以把它理解为：“我想知道&dev_waitq什么时候会被唤醒，请把我记下来。”

✅ 返回值决定`poll`是否立即返回

如果返回POLLIN，说明此刻就有数据可读，poll()立即返回；
如果返回 0，表示暂无可读写事件，进程进入睡眠；
只要mask不为 0，poll()就认为设备“已经就绪”。

所以，如果你发现poll()总是立即返回但read()却读不到数据，很可能是你在.poll函数里错误地设置了POLLIN。

✅ 必须配合`wake_up_interruptible()`使用

假设你的设备是一个串口，当 UART 中断触发时，你应该这么做：

void uart_data_received_isr(char c) { device_buffer[data_len++] = c; // 👉 关键！必须唤醒等待队列 wake_up_interruptible(&dev_waitq); }

如果没有这一句，即使数据已经到达，poll()也不会被唤醒，程序会一直等到超时。

完整驱动框架：从注册到销毁

为了让.poll正常工作，整个字符设备驱动需要正确初始化相关组件。以下是标准模板：

#include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/wait.h> static dev_t devno; static struct class *mychar_class; static struct cdev mychar_cdev; static wait_queue_head_t dev_waitq; // 文件操作结构体 static struct file_operations mychar_fops = { .owner = THIS_MODULE, .read = mychar_read, .write = mychar_write, .open = mychar_open, .release = mychar_release, .poll = mychar_poll, // 启用 poll 支持 }; static int __init mychar_init(void) { int ret; // 1. 动态分配设备号 ret = alloc_chrdev_region(&devno, 0, 1, "mychar"); if (ret) { pr_err("Failed to allocate char device region\n"); return ret; } // 2. 创建设备类和节点（/dev/mychar） mychar_class = class_create(THIS_MODULE, "mychar"); device_create(mychar_class, NULL, devno, NULL, "mychar"); // 3. 初始化 cdev 并添加到系统 cdev_init(&mychar_cdev, &mychar_fops); mychar_cdev.owner = THIS_MODULE; ret = cdev_add(&mychar_cdev, devno, 1); if (ret) { pr_err("Failed to add cdev\n"); goto err_cdev; } // 4. 初始化等待队列头 init_waitqueue_head(&dev_waitq); pr_info("Character device registered with major %d\n", MAJOR(devno)); return 0; err_cdev: device_destroy(mychar_class, devno); class_destroy(mychar_class); unregister_chrdev_region(devno, 1); return ret; } static void __exit mychar_exit(void) { cdev_del(&mychar_cdev); device_destroy(mychar_class, devno); class_destroy(mychar_class); unregister_chrdev_region(devno, 1); pr_info("Character device unregistered\n"); } module_init(mychar_init); module_exit(mychar_exit); MODULE_LICENSE("GPL");

⚠️ 注意事项：
-init_waitqueue_head(&dev_waitq);必须在驱动初始化阶段调用；
-class_create()和device_create()让 udev 自动创建/dev/mychar节点；
-.owner = THIS_MODULE防止模块在使用中被卸载。

用户空间怎么用？别忘了`O_NONBLOCK`

很多开发者忽略了这一点：.poll和O_NONBLOCK是一对黄金搭档。

正确的用户空间代码应该是这样：

#include <poll.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> int main() { int fd = open("/dev/mychar", O_RDWR | O_NONBLOCK); if (fd < 0) { perror("open failed"); return -1; } struct pollfd pfd = { .fd = fd, .events = POLLIN | POLLPRI, // 监听可读和高优先级数据 }; int ret = poll(&pfd, 1, 5000); // 最多等待 5 秒 if (ret > 0) { if (pfd.revents & POLLIN) { char buf[64]; ssize_t len = read(fd, buf, sizeof(buf)-1); if (len > 0) { buf[len] = '\0'; printf("Received: %s\n", buf); } } } else if (ret == 0) { printf("Timeout occurred\n"); } else { perror("poll failed"); } close(fd); return 0; }

为什么必须加`O_NONBLOCK`？

因为即使poll()返回了POLLIN，也不能保证read()一定能成功（例如数据在两次调用之间被其他线程读走了）。如果不设置O_NONBLOCK，read()仍可能阻塞。

因此，最佳实践是：
- 使用poll()判断“是否可能成功”；
- 使用O_NONBLOCK确保“失败时不阻塞”。

这才是真正的非阻塞 I/O 模型。

常见陷阱与调试技巧

❌ 陷阱一：忘记调用`poll_wait()`

static unsigned int broken_poll(struct file *filp, poll_table *wait) { if (data_available()) return POLLIN; return 0; }

这段代码看似合理，实则致命：永远不会被唤醒！因为你没有调用poll_wait()，内核根本不知道你要监听哪个队列。

✅ 正确做法永远是：

poll_wait(filp, &dev_waitq, wait);

哪怕你暂时不想睡，也要注册进去。

❌ 陷阱二：共享数据未加锁

在多核处理器上，中断上下文和用户进程可能同时访问data_len等变量。

解决方案是在访问临界资源时加自旋锁：

static DEFINE_SPINLOCK(buffer_lock); static unsigned int mychar_poll(struct file *filp, poll_table *wait) { unsigned long flags; unsigned int mask = 0; poll_wait(filp, &dev_waitq, wait); spin_lock_irqsave(&buffer_lock, flags); if (data_len > 0) mask |= POLLIN | POLLRDNORM; if (data_len < buffer_size) mask |= POLLOUT | POLLWRNORM; spin_unlock_irqrestore(&buffer_lock, flags); return mask; }

同样，在中断处理函数中修改data_len时也需加锁。

❌ 陷阱三：只支持水平触发（LT），不兼容`epoll`边缘触发（ET）

虽然poll本身只支持 LT 模式，但如果未来想迁移到epoll，建议在一次唤醒后尽量清空缓冲区，避免丢失事件。

例如，在read()函数中不要只读一个字节就返回，而是循环读取直到EAGAIN。

实际应用场景：工业数据采集系统

在一个典型的边缘网关中，我们需要同时采集多个 RS485 传感器的数据。每个传感器通过独立的 UART 接口连接。

传统做法：开多个线程，每个线程阻塞读一个串口 → 线程太多，调度开销大。

改进方案：所有设备都支持poll，主循环统一监控：

struct pollfd pfds[NUM_DEVICES]; for (int i = 0; i < NUM_DEVICES; i++) { pfds[i].fd = fds[i]; pfds[i].events = POLLIN; } while (running) { int ret = poll(pfds, NUM_DEVICES, 1000); if (ret <= 0) continue; for (int i = 0; i < NUM_DEVICES; i++) { if (pfds[i].revents & POLLIN) { read(fds[i], buf, sizeof(buf)); process_data(i, buf); } } }

结果：CPU 占用率从 75% 降到 8%，平均延迟减少 90%。