问题描述
这是我对打开文件进行读/写的理解.
Here is my understanding in opening to a file for reading/writing.
在应用层，我可以调用fopen()函数.
In the application layer, I can invoke the fopen() function.
fwrite() 函数将调用系统调用 open().
The fwrite() function will invoke a system call open().
操作系统收到open()调用后，会将命令传递给VFS(虚拟文件系统).
After the OS receives the open() call, it will pass the command to VFS(virtual file system).
VFS 查找文件名，包括所需的任何目录并进行必要的访问检查.
VFS looks up the file name, including any directories needed and does the necessary access checks.
如果这是在 RAM 缓存中，则不需要访问磁盘.如果没有，VFS 会向特定文件系统(可能是 EXT4)发送读取请求.
If this is in RAM cache then no disk access is needed. If not, the VFS sends a read request to the specific file system which is probably EXT4.
然后 EXT4 文件系统驱动程序将确定该目录位于哪个磁盘块中，然后向磁盘设备驱动程序发送读取命令.
Then the EXT4 file system driver will determine in what disk block that directory is located in. It will then send a read command to the disk device driver.
所以现在假设我想读取连接到电路板的 i2c 设备 A.并且文件目录是/dev/i2c/A
So now let's say I want to read an i2c device A attached to the board. And the file directory is /dev/i2c/A
是否有所有设备的主编号?例如，Linux 操作系统将 180 设置为 USB 的主编号.那么在设备端，每个USB设备中是否有一个主编号180?
Is there a major number for all devices? For example, Linux OS sets 180 as the major number for USB. So at the device side, is there a major number 180 in each USB device?
如果第一个问题的答案是否定的，那么Linux OS如何确定设备A是哪种类型的设备，是否仅根据文件目录?
If the answer to 1st question is NO, then how can the Linux OS determine which type of device A is, is it just according to the file directory?
我认为第二个问题的答案可能是:在启动初始化阶段，有一些代码已经使用 export() 之类的东西将该端口挂载到文件系统?所以实际上，在启动阶段之后，文件目录 /dev/i2c/A 存在于那里，并且它与 i2c 设备的主编号绑定.所以当我想打开 dev/i2c/A 时，操作系统会为我找到合适的 i2c 驱动程序，而不是 SPI 或 USB 驱动程序.我不确定这部分，我需要更多关于这方面的信息.
I think the answer to 2nd question maybe: at the boot initialization stage, there are some certain codes that have already mount that port to the file system using something like export()? So in fact, right after the booting stage, file directory /dev/i2c/A exists there and it is bind with a major number for i2c devices. So when I want to open dev/i2c/A, the OS will find the right i2c driver for me, not the SPI or USB driver.I'm not sure about this part, i need more information on this.
当设备在启动阶段后立即挂载到文件系统时，就会发生上述情况.那么如果我有一个usb会发生什么，这个usb在插入后如何安装到具有正确主编号180的文件系统?我猜在安装阶段开始之前插入 USB 时会出现 irq 吗?
The above situation happens when the device is mounted to the file system right after the booting stage. so what happened if I have a usb, how can this usb be mounted to the file system with the right major number 180 after it is plugged in? And I guess there is a irq when the usb is plugged in before the mounting stage starts?
推荐答案
参见:热插拔文档.如果您运行示例代码，您可以看到在从 USB 添加/删除设备时发送了 netlink 事件.这是 驱动程序模型.每个驱动程序都应该附加到一个BUS；这可以是platform、USB、I2C、SPI、PCI等.同样，在 sysfs 中，将有用于标识特定设备的条目.通常可以使用 I2C 地址来识别特定的客户端/从芯片.驱动程序模型还便于挂起、恢复、命令关闭等.
See: hotplug doc. If you run the sample code, you can see that a netlink event is sent when a device is added/removed from USB. This is part of the driver model. Each driver should attach to a BUS; this can be platform, USB, I2C, SPI, PCI, etc. As well, with in the sysfs, there will be entries to identify the particular device. Often an I2C address can be used to identify a particular client/slave chip. The driver model also facilitates suspend, resume, ordered shutdown, etc.
/dev/ 中的文件由 udev 或 mdev 用户空间程序创建.它们将名称与设备节点(主要、次要、字符/块)相关联.您可以使用 sysfs 和/或您的 udev 脚本根据 netlink 信息创建您想要的设备名称；其中大部分可用于 udev 脚本.
The files in /dev/ are created by udev or mdevuser-space programs . They associate a name with a device node (major,minor,char/block). You can use sysfs and/or your udev script to create a device name that you want based on netlink information; most of which is available to udev scripts.
对于i2c，总线主驱动程序通过运行probe来发现设备的地址.设备与具有表的特定驱动程序相关联.例如，stargate 机器文件 有 imote2_i2c_board_info 将 i2c 地址与驱动程序相关联.SPI 设备也有类似的表格.Platform 设备添加了 platform_add_devices().USB 和 PCI 设备由设备的类似 BUS 特定 ID 标识.通常一个机器文件(或最近的设备树)将两者关联起来.
另见:Linux 期刊 - I2C 驱动程序 pt1、Linux 期刊 - I2C 驱动程序 pt2
For i2c the bus master driver discovers the address of devices by running a probe. A device is associated with a particular driver with a table. For example, the stargate machine file has imote2_i2c_board_info which associates i2c addresses with drivers. A similar table exists for SPI devices. Platform devices are added with platform_add_devices(). USB and PCI devices are identified by similar BUS specific ids of a device. Usually a machine file (or more recently device tree) associates the two.
See Also: Linux Journal - I2C Drivers pt1, Linux Journal - I2C Drivers pt2
我认为一个令人困惑的原因是所有驱动程序/设备都是您在 /dev/ 目录中看到的那些.这不是真的.用户只能看到顶级驱动程序.许多 Linux 驱动程序/设备由 master 设备使用.它们可以形成设备的层次结构.通常只有顶级设备会暴露给用户.有诸如spi_write()之类的函数，更高级别的驱动程序可以使用这些函数通过SPI进行对话，SPI设备不会暴露给.声音和媒体/电视采集卡通常使用 SPI 设备，但用户永远不知道此 BUS 存在并正在使用.通常，多个卡供应商会在下面使用相同的芯片组.不是为每张卡编写驱动程序，而是只为卡编写一些胶水.然后使用 胶水 将一组通用的 chip 驱动程序连接在一起，在层次结构的顶部；这是暴露给用户空间的顶级驱动程序.这也允许 smart 芯片供应商创建系统集成商可以使用的良好驱动程序.
I believe a source of confusion is that all drivers/devices are those you see in the /dev/ directory. This is not true. Only top level drivers are seen by users. Many Linux drivers/devices are used by a master device. They can form a hierarchy of devices. Usually only the top level device is exposed to the user. There are functions such as spi_write(), that a higher level driver can use to talk via SPI, the SPI device is not exposed to user space. Sound and media/tv capture cards often use an SPI device, but the user never knows this BUS exists and is being used. Often multiple card vendors will use the same chip-sets underneath. Instead of writing drivers for every card, only some glue for the card is written. Then a generic collection of chip drivers are used with the glue to tie it all together at the top of the hierarchy; this is the top level driver that is exposed to user space. This also allows smart chip vendors to create good drivers that system integrators can use.
注 1: 对于 i2c 探针，我的意思是一个 I2C 消息，它请求总线上的所有注册地址.我不确定 probe 是否是正确的 i2c 命名法.
Note 1: By i2c probe, I mean an I2C message that requests all registered addresses on the bus. I am not sure if probe is the correct i2c nomenclature.
注意 2 平台 设备是 SOC 设备.它们没有关联的 BUS，所以平台是一个包罗万象的东西.通常，platform 设备与 CPU 集成在一起(SOC 代表片上系统).
Note 2 Platform devices are SOC devices. They have no associated BUS, so platform is a catch-all. Typically, platform devices are integrated with the CPU (SOC stands for system on chip).
这篇关于'/dev' 中的文件如何与 Linux 的设备型号匹配?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！