'/ dev'中的文件如何与Linux的设备模型匹配？

Question

这是我对开放阅读/写作文件的理解.

在应用程序层,我可以调用该fopen()函数.

该fwrite()函数将调用系统调用open().

操作系统收到open()呼叫后,会将命令传递给VFS(虚拟文件系统).

VFS查找文件名,包括所需的任何目录,并进行必要的访问检查.

如果这是在RAM缓存中,则不需要磁盘访问.如果没有,VFS会向特定文件系统发送一个读取请求,该请求可能是EXT4.

然后,EXT4文件系统驱动程序将确定该目录所在的磁盘块.然后它将向磁盘设备驱动程序发送读取命令.

---

所以现在让我说我想读一个连接到主板的i2c设备A. 文件目录是/ dev/i2c/A.

• 所有设备都有一个主要编号吗？例如,Linux OS将180设置为USB的主要编号.那么在设备方​​面,每个USB设备中是否有一个主要的数字180？

• 如果第一个问题的答案为否,那么Linux操作系统如何确定哪种类型的设备A,它只是根据文件目录？

• 我认为第二个问题的答案可能是:在启动初始化阶段,有一些代码已经使用export()之类的东西将该端口挂载到文件系统？事实上,在启动阶段之后,文件目录/ dev/i2c/A就存在,并且它与i2c设备的主要编号绑定.因此,当我想打开dev/i2c/A时,OS会为我找到合适的i2c驱动程序,而不是SPI或USB驱动程序.我不确定这部分,我需要更多相关信息.

• 在启动阶段后立即将设备安装到文件系统时会发生上述情况.那么如果我有一个usb会发生什么,在插入后,如何将这个usb安装到具有正确的主号码180的文件系统？我想在安装阶段开始之前插入usb时会有一个irq？

Answer 1

请参阅:hotplug doc.如果运行示例代码,则可以看到netlink添加/删除设备时发送的事件USB.这是驱动程序模型的一部分.每个司机都要附上一个BUS; 这可以是platform,USB,I2C,SPI,PCI,等,以及,随着sysfs,将有条目来识别特定设备.通常,I2C地址可用于识别特定的客户/从芯片.该驱动程序模型也有利于暂停,恢复,责令关闭等

在这些文件/dev/被创建udev或mdev用户空间程序.它们将名称与设备节点(major,minor,char/block)相关联.您可以使用sysfs和/或您的udev脚本根据netlink信息创建所需的设备名称; 其中大部分都可用于udev脚本.

编辑:对于i2c公交车司机师傅通过运行发现设备的地址probe^注1.设备与具有表的特定驱动器相关联.例如,星门机文件具有imote2_i2c_board_info其相关联i2c的地址与司机.SPI设备存在类似的表.Platform^注意2添加了设备platform_add_devices(). USB和PCI设备由设备的类似BUS特定ID 识别.通常,机器文件(或更近期device tree)将两者联系起来.
另请参阅:Linux Journal - I2C驱动程序pt1,Linux Journal - I2C驱动程序pt2

我认为混淆的一个原因是所有驱动程序/设备都是您在/dev/目录中看到的.这不是真的.用户只能看到顶级驱动程序.主设备使用许多Linux驱动程序/设备.它们可以形成设备层次结构.通常只有顶级设备才会暴露给用户.有一些功能,例如spi_write(),更高级别的驱动程序可以用来通话SPI,SPI设备不会暴露user space.声音和媒体/电视捕获卡通常使用SPI设备,但用户永远不知道这BUS存在并正在使用.通常,多个卡供应商将在下面使用相同的芯片组.不是为每张卡写驱动程序,而是只写一些卡的胶水.然后将一个通用的chip驱动程序集合与胶水一起使用,将它们连接在层次结构的顶部; 这是暴露的顶级驱动程序user space.这也使智能^TM芯片供应商能够创建系统集成商可以使用的良好驱动程序.

注1:通过i2c探测,我的意思I2C是请求总线上所有已注册地址的消息.我不确定探针是否是正确的i2c命名法.

注2, Platform器件是SOC器件.他们没有相关的BUS,所以平台是一个全能的.通常,platform设备与CPU集成(SOC代表片上系统).