Linux如何将设备文件与设备驱动程序链接？ open() 系统调用最终会调用设备驱动程序代码吗？

Question

我有一个关于Linux设备文件和驱动的问题，我目前的理解如下：

1. 当用户在某个设备文件上调用open() 时，内核会在某个时间点向设备文件的inode 询问read()/write() 函数。

   李>

2. 设备文件是由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() 系统调用的描述中）“将inode 对象的i_fop 字段设置为def_blk_fops 或def_chr_fops 文件操作表的地址，根据设备文件的类型。"这意味着所有块设备文件都具有相同的read()/write() 函数，但是用户如何与不同的设备通信呢？

我还检查了device_driver 结构，确实没有地方存储文件访问函数，那么open() 系统调用究竟是如何使用特定于设备的驱动程序执行其工作的呢？如果不在device_driver 中，设备特定的操作功能在哪里？

Answer 1

简短的回答，它知道根据主要和次要数字最终调用哪个开放函数。当您注册您的驱动程序时，您可以提供这些或获取自动生成的，无论是字符、块还是 tty。

使用 udev 或 systemd 或 mdev 还会自动在/dev 下创建设备。在某些情况下，嵌入式发行版（例如 buildroot）和字符设备不会自动发生这种情况，您需要手动进行。我建议查看“Linux Device Drivers, 3rd edition, Chapter 3: Char Drivers”了解更多详情。

Answer 2

以下适用于打开字符特殊设备。

当文件打开时，inode 对象的i_fop 指针被复制到文件对象的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 指针替换为来自struct cdev 的ops 指针，该指针由字符特殊设备的驱动程序设置。

如果文件对象的f_op->open不为空，则调用它，并由chrdev_open返回其返回值。否则，此字符特殊设备不需要特殊的“打开”处理并返回 0。

如果chrdev_open 返回0，则文件对象处于“打开”状态，其f_op 指针指向特定于驱动程序的文件操作。 open 系统调用最终会返回一个文件描述符。如果chrdev_open 返回负的errno 值，文件对象将被销毁，open 系统调用将返回-1，errno 将根据chrdev_open 的返回值设置。