inode的file_operations何时与字符设备的file_operations建立关联？

你对open系统调用中struct file *filp的f_op从inode的i_fop填充的理解是正确的。关于inode的i_fop何时、如何关联到cdev的ops，具体流程如下：

1. mknod创建设备文件的阶段
   执行mknod只是在文件系统中创建了一个特殊inode，仅记录了设备的主、次设备号，但此时这个inode的i_fop并未关联到驱动的cdev->ops——inode和字符驱动对象还没有任何绑定关系。

2. 第一次打开设备文件的关键绑定过程
   真正的关联发生在首次调用open打开该设备文件时：

   • 内核处理open系统调用时，会从设备文件的inode中取出主、次设备号，到全局的cdev_map映射表中查找对应的cdev对象（这个cdev是你之前调用cdev_add注册到内核的）。
   • 找到匹配的cdev后，内核会将inode->i_fop设置为cdev->ops，同时把inode->i_cdev指向该cdev对象，完成inode与字符驱动的绑定。
   • 随后内核才会调用filp->f_op->open（即cdev->ops->open）来执行设备的打开逻辑。

3. 后续打开设备的优化流程
   当再次打开同一个设备文件时，由于inode已经和cdev完成绑定，内核会直接使用已设置好的inode->i_fop来填充filp->f_op，无需再去cdev_map中查找匹配的cdev。

额外补充：cdev_add的作用仅在于将cdev与指定的主、次设备号关联，并加入cdev_map映射表，让内核知晓设备号与驱动对象的对应关系。这一步完全不涉及inode，inode是文件系统层面的对象，只有在访问设备文件时才会与驱动对象建立关联。

内容的提问来源于stack exchange，提问作者Diogo Landau