"/dev"中的文件如何与Linux的设备模型匹配? [英] How do the files in '/dev' match Linux's model of a device?

问题描述

这是我打开文件进行读写的理解.

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后将该USB挂载到具有正确的主号码180的文件系统上?而且我猜想在安装阶段开始之前插入USB时会出现问题吗?

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?

推荐答案

请参阅:驱动程序模型.每个驱动程序都应附加到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 ^注1 来发现设备的地址.设备与带有表的特定驱动程序相关联.例如， Linux Journal-I2C驱动程序pt1 ，

For i2c the bus master driver discovers the address of devices by running a probe^{Note 1}. 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^{Note 2} 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/目录中看到的驱动程序/设备.这不是真的.用户只能看到顶级驱动程序. master 设备使用许多Linux驱动程序/设备.它们可以形成设备的层次结构.通常，只有顶级设备向用户公开.有诸如spi_write()之类的功能，更高级别的驱动程序可用于通过SPI进行对话，而SPI设备不会暴露于user space.声音和媒体/电视捕获卡通常使用SPI设备，但用户永远不知道此BUS存在并正在使用.通常，多个卡供应商将在下面使用相同的芯片组.无需为每张卡写驱动程序，只为卡写一些胶水.然后，将chip驱动程序的通用集合与胶水一起使用，以将其全部捆绑到层次结构的顶部.这是暴露给user space的顶级驱动程序.这也允许 smart ^TM 芯片供应商创建系统集成商可以使用的良好驱动程序.

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^TM chip vendors to create good drivers that system integrators can use.

注1:通过i2c探针，我的意思是I2C消息，它请求总线上的所有已注册地址.我不确定探针是否正确的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 Platform设备是 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的设备模型匹配?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！