Detailed introduction to the Linux uevent attribute File System

Before giving you a detailed introduction to the Linux uevent attribute file, let's first understand the Linux system and then introduce the Linux uevent attribute file. Many kobject in sysfs have the Linux uevent attribute, which is mainly used for a communication interface between the kernel and udev (automatic device Discovery program; from the perspective of the communication interface netlink protocol socket between udev and the kernel, it does not need to know the Linux uevent attribute file of the device, but has an additional interface such as uevent.

It can be used by udevmonitor to send messages to udevd (udev background program) through the kernel, or to check the environment variables on netlink messages supported by the device, this feature is generally used by developers to debug the udev rule file. The udevtrigger debugging tool is implemented by writing the Linux uevent attribute file of each device.

These Linux uevent attribute files are generally writable. Among them, many Linux uevent attributes under the/sys/devices/tree support readable in newer kernels:
# Find/sys/-type f-name uevent-ls
110-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/uevent
14710-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/pcspkr/uevent
30750-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/vesafb.0/uevent
39150-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/serial8250/uevent
39410-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/serial8250/tty/ttyS2/uevent
39500-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/serial8250/tty/ttyS3/uevent
52040-rw-r -- 1 root 4096 December 12 21:10 \
/Sys/devices/platform/i8042/uevent
[...]
9120-rw-r -- 1 root 4096 December 12 21:17 \
/Sys/devices/pci0000: 00/0000: 00: 02.5/uevent
[...]

The last screenshot above is the Linux uevent attribute files of the SCSI hard drive controller device. These/devices/attribute files support writing. Currently, the supported write parameters include "add", "remove ", "change", "move", "online", "offline ". For example, you can write "add" to send a netlink message to udevd to repeat the related udev rule file. This function is useful for developers to debug udev rule files.
# Echo add>/sys/devices/pci0000: 00/0000: 00: 02.5/uevent use the sysfs attribute file of the driver (PCI), bind, unbind and new_id in the device drive/sys/bus/*/driver /... we can see that many drivers have three attributes: bind, unbind, and new_id,
# Find/sys/bus/*/drivers/-name bind-ls
...

Each device driver specifies in a program the hardware that can be used. For example, all PCI drivers use MODULE_DEVICE_TABLE to declare the PCI device Number of the PCI hardware that can be driven. However, drivers cannot predict the future. New hardware may be compatible with existing hardware methods in the future, so you can use existing hardware drivers to work. Before bind and unbind were invented, there was no other way to modify the DEVICE_TABLE section of the PCI device driver and recompile the driver, after bind and unbind are added to the 2.6 kernel, You can manually bind the device and the driver without re-compiling.

Some hardware devices can have multiple drives available, but at any time, only one driver can drive the hardware, in this case, bind/unbind can be used to force or not to use any driver. (pay attention to the selection of multiple drivers. A better management method is to use modprobe. the conf configuration file takes effect only after being restarted, while bind/unbind provides a temporary way to take effect immediately without restarting ;)

You can use them to forcibly bind a device or not to use a driver. The operation is through the bind and unbind interfaces.
# Find/sys/-type f \ (-name bind-or-name unbind-or-name new_id \)-ls
690-rw-r -- 1 root 4096 December 12 22:12 \
/Sys/devices/virtual/vtconsole/vtcon0/bind
30720 -- w ------- 1 root 4096 December 12 22:15 \
/Sys/bus/platform/drivers/vesafb/unbind
[...]
64890 -- w ------- 1 root 4096 December 12 22:09 \
/Sys/bus/pci/drivers/8139too/unbind
64900 -- w ------- 1 root 4096 December 12 22:09 \
/Sys/bus/pci/drivers/8139too/bind
64910 -- w ------- 1 root 4096 December 12 22:15 \
/Sys/bus/pci/drivers/8139too/new_id
The three Property files of the driver 8139too are not mentioned in this result,

# Find/sys/bus/pci/drivers/8139too/-ls
64350 drwxr-xr-x 2 root root0 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/
64360 lrwxrwxrwx 1 root root0 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/0000: 00: 0e. 0-> .. /.. /.. /.. /devices/pci0000: 00/0000: 00: 0e. 0
64850 lrwxrwxrwx 1 root root0 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/module->.../module/8139too
64880 -- w ------- 1 root 4096 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/uevent
64890 -- w ------- 1 root 4096 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/unbind
64900 -- w ------- 1 root 4096 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/bind
64910 -- w ------- 1 root 4096 December 12 22:08 \
/Sys/bus/pci/drivers/8139too/new_id
# Echo 0000: 00: 0e. 0>/sys/bus/pci/drivers/8139too/unbind
-Bash: echo: write error: No Device
# Ip addr
1: lo: Mtu 16436 qdisc noqueue state UNKNOWN
Link/loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
Inet 127.0.0.1/8 scope host lo
2: eth0: Mtu 1500 qdisc pfifo_fast state \
UNKNOWN qlen 1000
Link/ether 00: 14: 2a: d1: 16: 72 brd ff: ff
Inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
3: bond0: Mtu 1500 qdisc noop state DOWN
Link/ether 00: 00: 00: 00: 00 brd ff: ff
# Echo-n 0000: 00: 0e. 0>/sys/bus/pci/drivers/8139too/unbind
# Ip addr
1: lo: Mtu 16436 qdisc noqueue state UNKNOWN
Link/loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
Inet 127.0.0.1/8 scope host lo
3: bond0: Mtu 1500 qdisc noop state DOWN
Link/ether 00: 00: 00: 00: 00 brd ff: ff
# Echo-n 0000: 00: 0e. 0>/sys/bus/pci/drivers/8139too/bind
# Ip addr
1: lo: Mtu 16436 qdisc noqueue state UNKNOWN
Link/loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
Inet 127.0.0.1/8 scope host lo
3: bond0: Mtu 1500 qdisc noop state DOWN
Link/ether 00: 00: 00: 00: 00 brd ff: ff
4: eth0: Mtu 1500 qdisc noop state DOWN qlen 1000
Link/ether 00: 14: 2a: d1: 16: 72 brd ff: ff
This operation demonstrates how to forcibly unbind the "8139too" driver and forcibly bind the "8139too" driver to a PCI device "0000: 00: 0e. 0:

Write the bus number (bus_id) to the Linux uevent attribute to force unbinding;
The bus number (bus_id) written to the bind attribute is forced binding;
Note that it requires a bus number, which corresponds to the bus number of the PCI device according to "domain (4 bits): bus (2 bits): slot (2 bits ): function No. (unlimited) "can be found on the kobject node of the device. Other types of buses have different rules;

Note: In this example, "echo 0000: 00: 0e. 0> the first write command of/sys/bus/pci/drivers/8139too/unbind exits with "No such device" as an error, the subsequent "echo-n" command is successful. This is because the kernel is too strict in matching bus numbers. Generally, the "echo" command writes a string and ends the output with a line break, what the kernel receives is the bus_id string with this line break, which can be compared with the real bus_id string in the kernel data structure. Fortunately, this problem has been solved in the kernel of the latest 2.6.28 development. It changes this comparison function to a special character string comparison function and automatically ignores the line break at the end, test on 2.6.28-rc6 kernel. The echo command without the "-n" parameter can be successfully written.

The new_id attribute file can also solve the problem of a new device number in another way: it is a write-only drive property and can be used to write a new device number to it. It supports Writing 2 to 7 hexadecimal Integer Parameters, which represent the vendor, device, subvendor, subdevice, class, class_mask, driver_data has at least two because a PCI device is uniquely calibrated by the vendor ID (vendor) and device ID (device, if you do not enter the other five parameters, the default value is PCI_ANY_ID (0 xffff ).

54410 -- w ------- 1 root 4096 December 14 18:15 \
/Sys/bus/pci/drivers/8139too/new_id

The 8139too driver displays the list of currently statically supported device numbers, including the 10ec: 8139 devices in the current system, if a 8140 device meets the hardware communication protocol of the 8139 device in the future, you can use the 8139too driver to drive it, the operation is as follows # echo '10ec8140 '>/sys/bus/pci/drivers/8139too/new_id. It is very useful to debug the device without updating the driver. The preceding section describes the Linux uevent attribute file.

1. Analyze the future of the Linux Mobile Software Industry
2. Describes the hardware supported by Linux operating system installation and recognition.
3. Discuss and test the use of Fedora Linux hardware
4. Details about how to use Windows partitions in Linux
5. How will you recover the Linux files that have been accidentally deleted?