How do the files in '/ dev' match the Linux device model?
Here is my understanding when opening a file for reading / writing.
In the application layer, I can call the function fopen()
.
The function fwrite()
will call a system call open()
.
After the OS receives the call open()
, it will issue the command to the VFS (Virtual File System).
VFS looks for the filename, including any required directories, and performs the necessary access checks.
If it's in the RAM cache, no disk access is required. If not, the VFS sends a read request to the specific filesystem, which is probably EXT4.
The EXT4 file system driver will then determine in which disk block this directory is located. Then it will send a read command to the disk driver command.
So now let's say I want to read an i2c A device attached to the board. And the files directory is / dev / i2c / A
-
Is there a large number for all devices? For example, Linux OS sets 180 as the base number for USB. So, on the device side, does every USB device have a large 180 number?
-
If the answer to the 1st question is NO, then how can Linux OS determine what type of device A is, this is only according to the file directory?
-
I think the answer to the second question might be: in the boot initialization phase, are there some specific codes that have already connected this port to the filesystem using something like export ()? So there is actually a / dev / i 2c / A file directory just after the boot phase, and it is associated with the major number for i2c devices. So when I want to open dev / i2c / A, the OS will find the correct i2c driver for me, not the SPI or USB driver. I'm not sure about this part, I need more information on this.
-
The above situation occurs when the device is connected to the file system immediately after the boot phase. so what happened, if i have a USB drive, how can this USB drive be connected to the file system with the right major number 180 after it is connected? And I am assuming there is an irq when the USB is plugged in before the install stage starts?
source to share
See: hotplug document . If you run the example code, you can see the event is netlink
dispatched when a device is added / removed from USB
. This is part of the driver model . Each driver must connect to BUS
; it can be platform
, USB
, I2C
, SPI
, PCI
, etc. In addition, there sysfs
will be records to identify a specific device. Often, the address I2C
can be used to identify a specific client / slave chip. the driver model also makes it easier to suspend, resume, ordered shutdown, etc.
Files in /dev/
are created by user-space programs udev
or mdev
. They associate a name with a device node (main, minor, symbol / block). You can use sysfs
and / or your script udev
to create the desired device name based on the information netlink
; most of which are scriptable udev
.
Edit: For the i2c
master bus driver, detects the device address by running probe
Note 1 . The device is associated with a specific driver with a table. For example, a stargate machine has fileimote2_i2c_board_info
that associates addresses i2c
with drivers. A similar table exists for devices SPI
. Platform
Note 2 devices are added along with platform_add_devices()
. Devices USB
and are PCI
identified using identical BUS
device identifiers . Usually a machine file (or more recently device tree
) links them.
See also: Linux Journal - I2C pt1 drivers , Linux Journal - I2C pt2 drivers
I believe the source of the confusion is that all drivers / devices are the ones you see in the directory /dev/
. It is not true. Users only see top-level drivers . Many Linux drivers / devices are used by the host. They can form a hierarchy of devices. Typically, only the top level device is available to the user . There are features such as spi_write()
that a higher-level driver can use to talk through the SPI
device SPI
does not have access to user space
. Audio and Media / TV capture cards use the device frequently SPI
, but the user will never know what it isBUS
exists and is used. Often several card providers use the same chipset. Instead of writing drivers for each card, only a little bit of card glue is written . A generic collection of drivers is then chip
used with glue to tie it all together at the top of the hierarchy; this is the top-level driver available for user space
. It also allows smart TM chipmakers to create good drivers that system integrators can use.
Note 1: By probe i2c
I mean a message I2C
that asks for all registered addresses on the bus. I am not sure the probe is the correct nomenclature i2c
.
Note 2 Devices Platform
are SOC devices . They have no associated bus, so the platform is universal. Typically, devices are platform
integrated with a processor (SOC stands for system-on-a-chip).
source to share
Each device has a major and minor number. You can see them by doing
ls -n /dev
For some drivers, such as disk, major numbers are hardcoded. For others, it is dynamic. Minor numbers can be assigned dynamically as devices are discovered at runtime, not just at boot. The kernel maintains a table of internal device switches that maps dev numbers to the correct driver.
source to share