file_operations中的poll方法

file_operations结构体的poll方法是内核实现 **IO 多路复用（select/poll/epoll）** 的核心接口，用于让用户态程序高效查询设备 / 文件的 IO 状态（可读、可写、异常），避免无意义的阻塞或轮询。

poll方法的核心作用

用户态的select/poll/epoll本质是向内核查询 “哪些文件描述符（fd）处于就绪状态”，而内核层对每个 fd 的状态查询，最终都会调用该 fd 对应file_operations结构体的poll方法。

• 对字符设备 / 块设备驱动：实现poll方法后，用户态才能用select/poll/epoll监听设备的 IO 就绪状态（比如串口有数据可读、按键设备被按下、自定义设备可写入）。
• 对普通文件：内核已有默认实现（始终返回 “就绪”），无需开发者重写；但自定义驱动必须手动实现poll方法，否则用户态的 IO 多路复用会失效。

poll方法的内核原型

poll是struct file_operations的一个函数指针成员，内核中标准原型（Linux 3.10+，不同版本基本一致）：

// 头文件依赖：#include <linux/poll.h> unsigned int (*poll)(struct file *filp, struct poll_table_struct *wait);

参数说明

1. filp：文件指针，对应用户态的 fd，可通过它获取驱动的私有数据（filp->private_data）。
2. wait：轮询表结构体，核心作用是将当前进程加入到驱动的 “等待队列”，实现 “无就绪则阻塞，就绪则唤醒”，避免 CPU 空轮询。

返回值说明

返回位掩码，表示当前设备的 IO 就绪状态，内核定义了标准宏（需包含<linux/poll.h>）：

可以通过 ** 位或（|）** 返回多个状态，比如return POLLIN | POLLOUT;表示设备同时可读可写。

poll方法的核心实现逻辑

驱动中实现poll方法的固定三步法，这是内核的规范写法，缺一不可：

步骤 1：将进程加入等待队列（通过poll_wait）

内核提供封装函数poll_wait，专门用于将当前进程加入指定等待队列，该函数不会阻塞进程，仅完成 “入队注册”：

// 原型：void poll_wait(struct file *filp, wait_queue_head_t *wqh, poll_table *p); // 参数：filp-文件指针；wqh-驱动定义的等待队列头；p-poll方法的wait参数 poll_wait(filp, &dev->r_wait, wait); // 加入读等待队列 poll_wait(filp, &dev->w_wait, wait); // 加入写等待队列（可选）

• 等待队列头（wait_queue_head_t）是驱动提前定义的全局变量，用于管理等待该设备 IO 的进程。
• 必须先注册等待队列，否则内核无法在设备就绪时唤醒进程。

步骤 2：判断设备的 IO 就绪状态

根据驱动的私有数据标志位（比如dev->rx_ready表示有数据可读、dev->tx_ready表示可写入），判断当前设备是 “可读”“可写” 还是 “无就绪”。

• 标志位通常在驱动的中断处理函数中置位（比如串口收到数据，中断中设dev->rx_ready=1），在read/write 方法中复位（比如 read 读取数据后，设dev->rx_ready=0）。

步骤 3：返回就绪状态的位掩码

根据步骤 2 的判断结果，返回对应的内核宏（POLLIN/POLLOUT 等）；若无任何就绪状态，返回0，此时用户态的 select/poll 会将进程阻塞。

核心流程（用户态→内核态）

1. 用户态调用poll(fds, 1, 3000)→ 内核遍历pollfd，调用驱动的poll_drv_poll方法。
2. 驱动poll方法执行poll_wait，将进程加入读等待队列，然后判断rx_ready=1，返回POLLIN。
3. 内核收到POLLIN后，立即返回poll调用，用户态判断revents & POLLIN为真，调用read读取数据。
4. 驱动read方法拷贝数据后，复位rx_ready=0，返回用户态。
5. 下一次用户态poll→ 驱动poll方法返回0→ 内核将进程阻塞 3 秒，超时后返回0，用户态输出 “poll timeout”。

若在驱动中通过调试 fs / 中断 / 定时器重新置位g_poll_dev->rx_ready=1并唤醒等待队列：

// 唤醒读等待队列的进程（内核函数） wake_up_interruptible(&g_poll_dev->r_wait);

则用户态的poll会立即被唤醒，返回就绪状态，触发新一轮的read。

关键拓展：poll 与 select/epoll 的关系

用户态的select/poll/epoll最终都会调用内核层文件的poll方法，区别仅在于内核对就绪 fd 的管理方式：

1. select：基于位图，监听 fd 数量有限（默认 1024），每次调用都要遍历所有 fd，效率低。
2. poll：基于pollfd数组，无 fd 数量限制，但仍需遍历所有 fd，适合中少量 fd 场景。
3. epoll：基于红黑树 + 就绪链表，无需遍历所有 fd，仅处理就绪的 fd，适合高并发（万级 fd）场景。

对驱动开发者：只需实现poll方法，无需关心用户态用的是 select/poll 还是 epoll，内核会完成上层适配。

总结

1. file_operations的poll方法是内核与用户态 IO 多路复用的桥梁，自定义驱动需实现该方法才能支持 select/poll/epoll。
2. poll方法的实现遵循固定三步法：poll_wait入队 → 判断就绪标志 → 返回位掩码，poll_wait仅注册等待队列，不阻塞进程。
3. 就绪标志（如rx_ready）由中断 / 定时器置位，read/write复位，配合等待队列实现 “无就绪则阻塞，就绪则唤醒”。
4. 用户态通过struct pollfd指定监听的 fd 和事件，poll系统调用的返回值表示就绪的 fd 数量，revents表示具体的就绪事件。
5. 驱动实现poll后，用户态可高效管理多个设备的 IO 状态，避免传统read/write的阻塞或非阻塞轮询带来的性能损耗。