Shulou(Shulou.com)06/02 Report--

The use of Udev-- linux system to create device nodes

Linux exists in the form of device files. In earlier versions of Linux, the / dev directory contained device files for all possible devices. But because of this, it is difficult for Linux users to find device files that match the criteria in these large number of device files. Udev now generates device files only for devices connected to the Linux operating system. And udev can generate device files that match device attributes by defining a udev rule (rule), which can be kernel device name, bus path, vendor name, model, serial number, disk size, and so on.

Automatically manage device information dynamically: when devices are added / removed, the udev daemon listens to events from the kernel's uevent to add or delete device files under / dev, so udev can generate device files only for connected devices, instead of generating a large number of device files under / dev like the 2.4 kernel. In addition, you can use this feature to run external programs when a device joins, such as automatically disabling the touchpad when the mouse joins.

Use custom naming and management of devices: using the Udev rules file, udev defines kernel device names for all devices in / dev/, such as / dev/ sda, / dev/hda, / dev/fd, and so on. Because udev runs in user space (user space), Linux users can then operate on this information, for example, they can generate user-friendly device identities such as / dev/my_disk, / dev/nameusb, etc., and modify the settings such as parameter member user group permissions.

You need to know about things like the beginning.

? Sysfs:sysfs is a virtual file system (/ sys) in the Linux 2.6 kernel. It exports device and driver information from the device module of the kernel to user space (userspace). From this file system, Linux users can get the properties of many devices.

? Devpath: the devpath in this article refers to the relative path of a device under the sysfs file system (/ sys), which contains the properties file of the device. Most commands in udev operate on devpath. For example, the devpath for sda is / block/sda,sda2 and the devpath is / block/sda/sda2.

? Kernel device name: the name of the device in sysfs, which is the device file name used by udev by default.

Udev main configuration file

The main udev main configuration file is / etc/udev/udev.conf. This file is usually very short, and it may just contain a few lines of comments starting with #, and then have a few lines of options:

The absolute path set by udev_root=/dev/ # is equivalent to the root of creating chroot.

Storage address of the udev_rules=/etc/udev/rules.d/ # rule

Input level of udev_log=err # Log

Example of a rule profile for udev

The default rule configuration file is stored in / etc/udev/rules.d/, and we can enter this to see some rules built by RedHat by default for the device and some rules written by the hardware company.

When you enter the directory, you can see the configuration file with a prefix starting with two digits. You can use vi to enter the configuration file to view it. One line is a rule, and the default is from small numbers to large numbers. These indicate the order in which they take effect.

Before we use udev to write rules, let's look at an example

KERNEL==sd*, PROGRAM=/lib/udev/scsi_id-g-s% p, RESULT==123456, SYMLINK=%k_%c

Execution of this rule: if a kernel device name begins with sd and the SCSI ID is 123456, a symbolic link "sda_123456" is generated for the device file. % p% k% c see "values of udev and callable replacement operators" below

Rule profile for udev

In a rule file, all non-blank lines are treated as a rule, except for lines that begin with "#" (comments), but a rule cannot be extended to multiple lines. Rules are composed of multiple key-value pairs (key-value pairs) separated by commas. Key-value pairs can be divided into conditional matching key-value pairs (hereinafter referred to as "matching key") and assignment key pairs (hereinafter referred to as "assignment key"). A rule can have multiple matching keys and multiple assignment keys. The matching key is all the conditions that match all the attributes of a device. When the attribute of a device matches all the matching keys in the rule, the rule is considered to be effective, and then the assignment of the rule is performed according to the content of the assignment key.

The rules in the rules file consist of a series of key / value pairs separated by a comma (,).

You can also see these configurations in the above example, but I think you may wonder why KERNEL is the matching key while NAME and MODE are the assignment keys. This is determined by the middle operator (operator).

It is a match key only if the operator is "= =" or "!"; if it is any other operator, it is an assignment key.

The match key and assignment key operators are explained in the following table:

Operator matching or assignment t interpretation

--

= = match equality comparison

! = match unequal comparison

Assignment assigns a specific value to the key, which can override the previous assignment.

+ = assign append a specific value to an existing key

: = assign a specific value to the key, and it is impossible for subsequent rules to override it.

Match key for udev rule:

Key meaning

--

The behavior of the ACTION event (uevent), for example: add (add device), remove (delete device).

The device name that KERNEL sees in the kernel, such as sd* for any SCSI disk device

DEVPATH kernel device recording, such as / devices/*

SUBSYSTEM subsystem name, for example: the subsystem of sda is block.

The name of the BUS bus, such as IDE,USB

The name of the DRIVER device driver, such as ide-cdrom

ID device name independent of kernel name

The value of the SYSFS {value} sysfs property, which can represent any

ENV {key} environment variable, which can represent any

PROGRAM executable external program, if the program returns a value of 0, the key is considered true (true)

The standard output returned by the last PROGRAM call to RESULT.

The file name of the device file created by NAME according to this rule.

Note: only the NAME description on the first line is valid, and the rest is ignored.

If you want to use more than two names to access a device, consider the SYMLINK key.

SYMLINK generates symbolic links for device files under / dev/. Because udev can only generate one device file for a device

So in order not to overwrite the files generated by the system's default udev rules, symbolic links are recommended.

Subordinate groups of OWNER device files

The group in which the GROUP device file belongs.

Permissions for MODE device files, using octal

List of programs executed by RUN for the device

The name tag used by LABEL for internal control in the configuration file (the following GOTO service)

GOTO jumps to matching rules (identified by LABEL), which is somewhat similar to GOTO in a programming language

IMPORT {type} imports a file or a rule set generated by the execution of a program into the current file

WAIT_FOR_SYSFS waits for the creation of a specific device file. It is mainly used for timing and dependency problems.

PTIONS-specific options:

Last_rule enforces terminal rules for this type of device

Ignore_device ignores the current rule

Ignore_remove ignores the next request and removes the request.

All_partitions creates device files for all disk partitions.

--

Important assignment keys of udev

Quote

NAME: the device file name generated under / dev. Only the first assignment to the NAME of a device takes effect, and then the matching rules and then the NAME assignment to the device will be ignored. If there is no rule to assign a value to the device's NAME, udev will use the kernel device name to generate the device file.

SYMLINK: generate symbolic links for device files under / dev/. Because udev can generate only one device file for a device, symbolic links are recommended in order not to overwrite files generated by the system's default udev rules.

OWNER, GROUP, MODE: set permissions for the device.

ENV {key}: import an environment variable.

--

We give a column to explain how to use these keys. The following example comes from the standard configuration file for the Fedora Core 5 system.

KERNEL== "*", OWNER= "root" GROUP= "root", MODE= "0600"

KERNEL== "tty", NAME= "% k", GROUP= "tty", MODE= "0666", OPTIONS= "last_rule"

KERNEL== "scd [0-9] *", SYMLINK+= "cdrom cdrom-%k"

KERNEL== "hd [an ide]", BUS== "ide", SYSFS {removable} = = "1", SYSFS {device/media} = = "cdrom", SYMLINK+= "cdrom cdrom-%k"

ACTION== "add", SUBSYSTEM== "scsi_device", RUN+= "/ sbin/modprobe sg"

The above example shows five rules, each beginning with the KERNEL or action key:

* the first rule is default. It matches any device recognized by the kernel, and then sets the subordinate group of these devices to root, the group to root, and the access mode to 0600 (- rw---). This is also a secure default setting that ensures that only root can read and write to all devices by default.

* the second rule is also a more typical rule. It matches the end device (tty) and then sets the new permission to 0600, which is in the group tty. It also sets a special device file name:% K. In this example,% k represents the kernel name of the device. That means that the kernel recognizes the names of these devices and creates the file names of the devices.

* KERNEL== "scd [0-9] *" at the beginning of the third line, indicating the SCSI CD-ROM driver. It creates a pair of device symbolic connections: cdrom and cdrom-%k.

* the fourth line, the beginning of KERNEL== "hd [a Murz]", indicates the ATA CDROM drive. This rule creates the same symbolic link as the rule above. The ATA CDROM driver needs the sysfs value to distinguish other ATA devices because SCSI CDROM can be uniquely recognized by the kernel. .

* the fifth line begins with ACTION== "add", which tells udev to add / sbin/modprobe sg to the list of commands that will be executed when any SCSI device is added to the system. The effect is that the computer should add sg kernel modules to detect new SCSI devices.

Of course, the above are just a few examples, and if your system uses udev, you should be able to see more rules. If you want to change the permissions of the device or create symbolic links to the letter, you need to familiarize yourself with these rules, especially to pay close attention to the devices you modify.

The value of udev and the callable replacement operator

The keys and operators in the key-value pair are all introduced, and finally the value (value). Linux users are free to customize the values of the udev rule file.

For example: my_root_disk, my_printer. You can also reference the following replacement operator:

--

$kernel,% k: the kernel device name of the device, for example: sda, cdrom.

$number,% n: the kernel number of the device, for example: the kernel number of sda3 is 3.

$devpath,% p: the devpath path of the device.

$id,% b: the ID number of the device in devpath.

$sysfs {file},% s {file}: the contents of the file in the sysfs of the device. It is actually the property value of the device.

For example: $sysfs {size} indicates the size of the device (disk).

$env {key},% E {key}: the value of an environment variable.

$major,% M: major number of the device.

$minor% m: minor number of the device.

$result, the result returned by% c:PROGRAM

$parent,% P: the device file name of the parent device.

$root, the value of% r:udev_root, defaults to / dev/.

$tempnode,% N: temporary device name.

%%: symbol% itself.

$: symbol $itself.

Query of information required by udev rules

A commonly used command to check the matching key information above

Udevinfo-a-p $(udevinfo-Q path-n / dev/sda1)

The above command uses udevinfo twice:

The first time is to return the sysfs device path (it is usually different from the path of the Linux device file name we see-/ dev/hda--)

The second time is to query the device path, and the result will be a summary of unusual syfs information.

Udevinfo-a-p / sys/class/net/eth0

Scsi_id-g-s / block/sda

Scsi_id-g-x-s / block/sda/sda3

Ata_id / dev/hda

Testing and effectiveness of udev information

After finding out, after writing the rules according to the contents of the above file, how to test

Udevtest / block/sda

Start_dev # command to restart the udev daemon

This operation will re-query all the rule files in the rules directory for all devices, and then perform the behavior in the matching rules.

This command is usually used to make the new rule file take effect immediately.

-- data collation network

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.