01

60 秒回答模板

驱动异步通知可以理解成：用户程序先告诉内核“这个文件描述符有事件时通知我”。用户态通常打开设备后用 fcntl 设置 F_SETOWN 为当前进程，再设置 O_ASYNC。驱动的 file_operations 里实现 .fasync，在里面调用 fasync_helper，把当前文件和进程关系挂到驱动维护的 fasync 队列。之后设备中断或底半部发现数据准备好时，不是直接把数据塞给用户，而是调用 kill_fasync 发送 SIGIO，并带上 POLL_IN 等事件类型。用户态收到信号后再调用 read 或用 signalfd 处理，把数据真正读走。面试里要强调异步通知只是事件提醒，不是可靠数据队列；仍要处理并发、缓冲区、丢信号、进程退出和 close 时从 fasync 队列移除，实际项目常和 poll/epoll、wait queue 一起设计。

考点 订阅到通知
难度 真实面经题
回答目标 说明自己理解字符设备异步通知的用户态配置、驱动回调和可靠性边界。
02

深入解析

01

用户态先订阅

应用打开设备文件后设置 owner 和 O_ASYNC，告诉内核该文件描述符发生异步事件时向哪个进程或进程组发信号。没有这个订阅动作，驱动即使调用通知也找不到目标。

02

驱动用 fasync 保存订阅关系

驱动实现 .fasync 回调，并用 fasync_helper 维护 fasync_struct 链表。open/close 或标志变化时都会更新这条链，避免进程退出后仍通知旧对象。

03

数据就绪时只发事件

中断处理或工作线程发现缓冲区有数据后，调用 kill_fasync 发送 SIGIO。信号告诉应用可以读，但数据仍在驱动缓冲区里，应用必须继续 read 才能消费。

04

工程上要防丢和防竞态

信号可能合并，不能把每个信号等同于一条数据。驱动要用环形缓冲或队列保存数据，用锁保护状态，并支持 poll/阻塞 read 作为更稳妥的事件消费方式。

03

易错点

  • 把异步通知说成驱动直接把数据推到用户空间。
  • 漏掉用户态 F_SETOWN 和 O_ASYNC，导致订阅关系不完整。
  • 没有在 close 或 fasync 关闭时清理队列，留下悬挂通知。
  • 认为一个信号对应一条数据，忽略信号合并和缓冲区设计。
04

面试官追问

异步通知和 poll/epoll 有什么区别？

异步通知通过信号主动提醒进程；poll/epoll 是应用等待文件描述符就绪。实际项目中 epoll 更容易统一管理多个 fd，异步信号要小心处理重入和信号合并。

收到 SIGIO 后能不能在信号处理函数里做大量读写？

不建议。传统信号处理函数可安全调用的函数有限，常见做法是记录标志、写 eventfd，或用 signalfd 在主循环里处理。

如果面试官让你现场排查，你会先看哪些证据？

我会先看 dmesg 和返回码，再查 /sys 下设备、驱动和资源状态，必要时加 trace/ftrace 或最小日志，先证明问题出在设备生成、匹配、资源获取、回调路径还是用户态交互。