我对Linux设备文件和驱动程序有疑问，根据我目前的理解如下：
当用户调用open()某个设备文件时，内核会在某个时间点向inode设备文件询问read()/write()函数。
设备文件是由udev之前根据/sys文件夹inode中的设备创建的，这意味着设备文件的i_fop字段应指向指向知道如何与设备通话的功能的字段，例如read/write/mmap/ioctl/poll。这意味着每个设备文件的inode->i_fop字段应指向不同的file_operations结构。
如果是这样，设备驱动程序将提供这些read()/write()功能，也许是完整的file_operations结构，包括read/write/mmap/ioctl等。
现在，ULK说（在open()对设备文件的syscall的描述中）“根据设备文件的类型，i_fop将inode对象的字段设置为def_blk_fops或def_chr_fops文件操作表的地址。” 这意味着所有块设备文件都具有相同的read()/write()功能，但是用户如何与其他设备通信？
我还检查了该device_driver结构，实际上，没有位置存储文件访问功能，那么open()syscall如何使用设备特定的驱动程序执行其工作呢？设备专用的操作功能（如果不在其中）住device_driver哪里？
以下内容适用于打开字符专用设备。
打开文件时，i_fop来自inode对象的f_op指针将复制到文件对象的指针。对于字符特殊设备，这指向def_chr_fops。def_chr_fops.open指向chrdev_open，因此chrdev_open(inode, filp)在打开任何字符特殊设备时称为。
chrdev_open查看其注册struct cdev对象集，这些对象将inode的主要/次要数字（组合成一个dev_t数字）映射到特定的注册对象struct cdev。如果未struct cdev找到匹配项，则返回-ENXIO。否则，它将用中的f_op指针替换文件对象中的ops指针，该指针struct cdev是由驱动程序为字符特殊设备设置的。
如果文件对象的f_op->open非null，则将调用它，并通过返回其返回值chrdev_open。否则，此字符特殊设备不需要特殊的“打开”处理，并且返回0。
如果chrdev_open返回0，则文件对象处于“打开”状态，并且其f_op指针指向特定于驱动程序的文件操作。open最终，系统调用将返回文件描述符。如果chrdev_open返回负的errno值，则文件对象将被销毁，open系统调用将返回-1并将errno根据from中的返回值进行设置chrdev_open。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句