30 - udev subsystem

Lecture



In previous lectures, we sometimes mentioned the udev subsystem. You should already understand in general terms what udev is and why it is needed. The easiest way to explain the purpose of the udev subsystem is based on the USB bus and the devices connected to it. When a USB device is connected to the computer, the kernel at the USB bus service level records the connection event of the new device. The list of such events can be viewed by executing *** dmesg . Here is an example of events that the kernel registers when a flash drive is connected:

one
2
3
four
five
6
7
eight
9
ten
eleven
12
13
14
15
sixteen
[962726.528540] usb 2-2: new high speed usb device using ehci_hcd and address 8
[962726.663367] usb 2-2: configuration # 1 chosen from 1 choice
[962726.665095] scsi9: SCSI emulation for USB Mass Storage devices
[962726.665328] usb-storage: device found at 8
[962726.665335] usb-storage:
[962731.664264] usb-storage: device scan complete
[962731.664971] scsi 9: 0: 0: 0: Direct-Access OCZ RALLY2 8.07 PQ: 0 ANSI: 2
[962731.665787] sd 9: 0: 0: 0: Attached scsi generic sg5 type 0
[962731.670693] sd 9: 0: 0: 0: [sde] 7843840 512-byte logical blocks: (4.01 GB / 3.74 GiB)
[962731.671175] sd 9: 0: 0: 0: [sde] Write Protect is off
[962731.671182] sd 9: 0: 0: 0: [sde] Mode Sense: 03 00 00 00
[962731.671188] sd 9: 0: 0: 0: [sde] Assuming drive cache: write through
[962731.677810] sd 9: 0: 0: 0: [sde] Assuming drive cache: write through
[962731.677826] sde: sde1
[962732.148443] sd 9: 0: 0: 0: [sde] Assuming drive cache: write through
[962732.148456] sd 9: 0: 0: 0: [sde] Attached SCSI removable disk

Before udev, it was necessary to manually find the connected devices and configure their operation in the system. Now udev takes over the job. When you connect a flash drive to a computer with a modern Linux distribution, all configuration and mounting of the file system occurs automatically.

The sysfs file system is very closely associated with udev , which is mounted in the / sys directory. The / sys directory displays and provides access to the hardware configuration of the computer. In other words / sys is a display of the hardware configuration of the computer. The contents of the / sys directory dynamically change as the hardware configuration changes.

If you stop the udev daemon, when the flash drive is connected, the kernel will register events, the / sys directory will change, but the flash drive file system will not be mounted. Moreover, you will not see the new device in the / dev directory either, since it is udev that creates a block device there that is a flash drive.

So let's summarize a little. The task of the kernel is to determine changes in the hardware configuration of the system, register these changes, and make changes to the / sys directory. The task of the udev subsystem is to further integrate and configure the device in the system (display it in the / dev directory ), and provide the user with a device that is ready for operation.

The udev subsystem configures devices in accordance with the specified rules. The rules are contained in files in the /etc/udev/rules.d/ directory. Also files with rules can be contained in the / etc / udev / directory. All rule files are listed alphabetically.

Consider the line with the rule from the rules file and get acquainted with the basic principles of the rules:

one
SUBSYSTEMS == "scsi", KERNEL == "sr [0-9] *", NAME = "scd% n", SYMLINK + = "sr% n"

In the line we see 4 pairs of expressions separated by a comma. The first two pairs are the so-called filters that allow you to identify the device. In the example, SUBSYSTEMS == ”scsi” indicates that the device must be a SCSI device, and the pair KERNEL == ”sr [0-9] *” identifies the device by the name it (device) received from the system core. That is, this rule will be applied to a SCSI device named sr0 or sr1 , etc.

Next are the pairs of actions that will be performed with devices that correspond to the filter. NAME = ”scd% n” - this entry indicates that a device file will be created for the device in the / dev directory with the name scd0 or scd1 , etc. The digit will depend on the digit in the device name. Instead of % n , the number from the name will be substituted. If the device name is sr0 , then scd% n is converted to scd0 . The % k substitution is also very often used. % k is the full device name. That is, instead of % k, sr0 will be substituted. If one device file name ( / dev / scd0 ) is not enough, you can create symbolic links - SYMLINK + = ”sr% n” . This expression will create in the / dev directory a symbolic link named sr0 to the device / dev / scd0 file . Note that the + = operator is used.

For each device connected, the kernel creates corresponding entries in the / sys directory. The device, besides belonging to a subsystem and a name, also has many attributes, such as name, model, serial number and others. You can also identify devices by attribute names. To do this, use the expression ATTRIB {attribute name} == attribute value .

Perform the following practical task. Let's write a rule that will create a symbolic link to the plug-in flash drive in the / dev directory . Flash drive is identified by serial number. We connect the flash drive and with the help of the dmesg command we look at the name that was assigned by the kernel for this drive:

one
2
3
four
...
[962731.665787] sd 9: 0: 0: 0: Attached scsi generic sg5 type 0
[962731.670693] sd 9: 0: 0: 0: [sde] 7843840 512-byte logical blocks: (4.01 GB / 3.74 GiB)
...

The drive name is sde . Next, use the com *** udevinfo . Com *** and udevinfo - designed to view the udev database, as well as to obtain information about devices from the / sys directory. More information about the command in man udevinfo , now consider only a special case of use. The next comma *** will give information about the device:

one
2
3
four
five
6
7
eight
9
ten
eleven
12
udevinfo -q all -n sde

P: /devices/pci0000:00/0000:00:13.2/usb2/2-2/2-2:1.0/host8/target8
N: sde
W: 85
S: block / 8: 64
S: disk / by-id / usb-OCZ_RALLY2_ST1A9BFE-0: 0
...
...
E: DKD_PARTITION_TABLE_SCHEME = mbr
E: DKD_PRESENTATION_NOPOLICY = 0
E: DEVLINKS = / dev / block / 8: 64 / dev / disk / by-id / usb-OCZ_RALLY2_ST1A9BFE-0: 0

We are interested in the very first line that contains the path to the remaining information about the device recorded in the / sys directory. To get this information you need to execute com *** from udevinfo -a -p path . In order not to type such a long way you can write such a com *** ***:

one
udevinfo -a -p $ (udevinfo -q path -n sde)

As a result, we get a long list of attributes and values ​​in the form ready for use in udev rules. Below is a small fragment of the results:

one
2
3
four
five
6
7
eight
9
ten
eleven
12
13
14
15
sixteen
17
18
nineteen
20
21
22
23
...
SUBSYSTEMS == "usb"
DRIVERS == "usb"
ATTRS {bNumInterfaces} == "1"
ATTRS {bConfigurationValue} == "1"
ATTRS {bmAttributes} == "80"
ATTRS {bMaxPower} == "100mA"
ATTRS {urbnum} == "4811"
ATTRS {idVendor} == "058f"
ATTRS {idProduct} == "6387"
ATTRS {bcdDevice} == "0100"
ATTRS {bDeviceClass} == "00"
ATTRS {bNumConfigurations} == "1"
ATTRS {bMaxPacketSize0} == "64"
ATTRS {speed} == "480"
ATTRS {busnum} == "2"
ATTRS {devnum} == "4"
ATTRS {version} == "2.00"
ATTRS {maxchild} == "0"
ATTRS {quirks} == "0x0"
ATTRS {authorized} == "1"
ATTRS {serial} == "ST1A9BFE"
...

Now you can make a rule. For example:

one
SUBSYSTEMS == "usb", ATTRS {serial} == "ST1A9BFE", SYMLINK + = "MyFlashRally"

This rule will be applied to all USB subsystem devices whose serial number is ST1A9BFE . As a result, a symbolic link should be created to such a device in the / dev directory .

Create the file /etc/udev/rules.d/10-myudev.rules , insert our rule into it. Turning off the flash drive, overloading the udev daemon and reconnecting the flash drive. Execute com *** at ls -l / dev | grep myflash :

one
2
$ ls -l / dev / | grep myflash
lrwxrwxrwx 1 root root 3 2010-03-19 21:19 MyFlashRally -> sde

We see that the udev subsystem has executed our rule and created a symbolic link to the sde device file.

In most cases, the subsystem works correctly and to intervene in its work in practice is very rare. For a more in-depth study of the rules, I recommend reading the man udev help file, as well as reviewing and parsing the rules in existing udev rule files.


Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

LINUX operating system

Terms: LINUX operating system