file_operations：Linux 字符设备驱动的呼吸节律
你有没有遇到过这样的场景：
在调试一个 LED 驱动时，open()成功了，但write()却始终返回-EFAULT；
或者在多进程同时控制同一个串口设备时，两个ioctl()调用相互覆盖寄存器配置，导致设备行为诡异；
又或者模块卸载后，用户空间还在调用read()，内核直接 panic —— 堆栈里赫然出现你的函数名。
这些不是玄学故障，而是file_operations这个看似简单的结构体，在没被真正理解之前，悄悄埋下的所有地雷。
它不是一份待填空的表格，也不是一段可有可无的初始化代码。它是字符设备驱动的心跳线：每一次open、read、ioctl、close，都在按它的节奏跳动；它也是内核与硬件之间的神经突触——信号传得准不准、快不快、稳不稳，全看这组函数指针怎么连、怎么护、怎么断。
它到底是什么？别被“结构体”三个字骗了
先扔掉教科书式的定义。file_operations不是数据容器，而是一张静态路由表，由 VFS（虚拟文件系统）在设备打开瞬间查表 dispatch。它不保存状态，不分配内存，不参与调度——它只做一件事：告诉内核：“当用户要干某件事时，请跳转到我指定的函数去执行。”
它的声明藏在<linux/fs.h>里，但真正关键的，从来不是那一长串函数指针，而是谁在用它、怎么用它、用错会怎样。
static const struct file_operations mydev_fops = { .owner = THIS_MODULE, .open = mydev_open, .read = mydev_read, .unlocked_ioctl = mydev_ioctl, .release = mydev_release, .llseek = no_llseek, };注意这五个细节：
const是铁律：一旦注册进内核，这张表就冻结了。你不能在运行时改.read指针，就像不能给正在行驶的高铁换轨道。owner = THIS_MODULE不是形式主义：它让内核知道“这个函数属于哪个模块”，从而在rmmod时检查是否还有活跃调用。没有它？rmmod后read()仍可能被执行，野指针直接落地成盒。.llseek = no_llseek是态度：不是“忘了写”，而是明确拒绝寻址能力。对 FIFO、LED、按键这类无偏移概念的设备
