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

This article is from: https://www.ibm.com/developerworks/cn/linux/l-cn-udev/index.html

Overview:

It is often difficult for Linux users to identify the same type of device name, such as eth0, eth2, sda, sdb, and so on. By looking at the kernel device names of these devices, users can usually know what type of devices they are, but they don't know which device they want. For example, in a list of device names (/ dev/sd*) filled with local and fiber-optic disks, the user cannot find a disk with the serial number "35000c50000a7ef67". In this case, udev can dynamically generate the desired device files or device links in the / dev directory to help users find the device files they need quickly and easily.

Introduction to udev what is udev?

Udev is a function in the Linux2.6 kernel, which replaces the original devfs and becomes the default device management tool of Linux. Udev runs as a daemon and manages the device files in the / dev directory by listening for the uevent sent by the kernel. Unlike previous device management tools, udev runs in user space (user space), not kernel space (kernel space).

Benefits of using udev:

As we all know, all devices exist in the form of device files in Linux. In earlier versions of Linux, the / dev directory contained device files for all possible devices. It's hard to imagine how Linux users can 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.

Dynamic management: when devices are added / removed, the udev daemon listens for uevent from the kernel to add or remove device files under / dev, so udev only generates device files for connected devices, not a large number of empty device files under / dev. Custom naming rules: through the Linux default 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 flexibly generate highly identifiable device file names, such as / dev/boot_disk, / dev/root_disk, / dev/color_printer, and so on, through custom rule files. Set device permissions and owner / group: udev can set device file permissions and device file owner / group according to certain conditions. The approach to implementation varies from version to version of udev, which is explained in more detail in how to configure and use udev.

The following flowchart shows the process of adding / removing device files by udev.

Figure 1. Udev workflow flow chart:

Related terms: device files: because this article explains udev in a more popular way, device files generally refer to files that can be used by applications to interact with device drivers under / dev/. There is no special distinction between device files, device nodes or device special files. Devfs: devfs is the early device management tool of Linux and has been replaced by udev. 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. How to configure and use udev

The following describes the configuration and use of udev on the platforms of RHEL4.8 and RHEL5.3 respectively:

Download and install udev

Starting with Fedora3 and Red Hat Enterprise4, udev is the default device management tool without having to download and install it separately.

Listing 1. Check the version and operation of udev in RHEL4.8

one

two

three

four

five

six

[root@HOST_RHEL4 dev] # rpm-qa | grep-I udev

Udev-039-10.29.el4

[root@HOST_RHEL4 ~] # uname-r

2.6.9-89.ELsmp

[root@HOST_RHEL4 ~] # ps-ef | grep udev

Root 21826 1 0 Dec09? 00:00:00 udevd

Listing 2. Check the version and operation of udev in RHEL5.3

one

two

three

four

five

six

[root@HOST_RHEL5 ~] # rpm-qa | grep-I udev

Udev-095-14.19.el5

[root@HOST_RHEL5 sysconfig] # uname-r

2.6.18-128.el5

[root@HOST_RHEL5 sysconfig] # ps-ef | grep udev

Root 5466 1 0 18:32? 00:00:00 / sbin/udevd-d

If Linux users want to update the udev package, they can download and install it from http://www.kernel.org/pub/linux/utils/kernel/hotplug/.

Configuration file for udev (/ etc/udev/udev.conf)

Listing 3. RHEL 4. Configuration file of udev under 8

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

twenty-four

twenty-five

twenty-six

twenty-seven

twenty-eight

twenty-nine

thirty

thirty-one

thirty-two

thirty-three

thirty-four

thirty-five

thirty-six

[root@HOST_RHEL4 dev] # cat / etc/udev/udev.conf

# udev.conf

# The main config file for udev

#

# This file can be used to override some of udev's default values

# for where it looks for files, and where it places device nodes.

#

# WARNING: changing any value, can cause serious system breakage!

#

# udev_root-where in the filesystem to place the device nodes

Udev_root= "/ dev/"

# udev_db-The name and location of the udev database.

Udev_db= "/ dev/.udev.tdb"

# udev_rules-The name and location of the udev rules file

Udev_rules= "/ etc/udev/rules.d/"

# udev_permissions-The name and location of the udev permission file

Udev_permissions= "/ etc/udev/permissions.d/"

# default_mode-set the default mode for all nodes that have no

# explicit match in the permissions file

Default_mode= "0600"

# default_owner-set the default owner for all nodes that have no

# explicit match in the permissions file

Default_owner= "root"

# default_group-set the default group for all nodes that have no

# explicit match in the permissions file

Default_group= "root"

# udev_log-set to "yes" if you want logging, else "no"

Udev_log= "no"

Linux users can set the following parameters through this file:

The directory where the devices generated by udev _ root:udev are stored. The default value is / dev/. It is recommended that you do not modify this parameter because many applications call device files from this directory by default. The database or directory where the udev_db:udev information is stored. The default value is / dev/.udev.tdb. The name or directory of the udev_rules:udev rule file. The default value is / etc/udev/rules.d/. The name or directory of the udev_permissions:udev permission file. The default value is / etc/udev/permissions.d/. Default_ mode/ default_owner/ default_group: if the permissions of the device file are not specified in the permissions file, this parameter is used as the default permission. The default values are: 0600/root/root. Udev_log: whether the switch for syslog to record udev logs is required. The default value is no.

Listing 4. Configuration file for udev under RHEL5.3

one

two

three

four

five

six

seven

[root@HOST_RHEL5 ~] # cat / etc/udev/udev.conf

# udev.conf

# The initial syslog (3) priority: "err", "info", "debug" or its

# numerical equivalent. For runtime debugging, the daemons internal

# state can be changed with: "udevcontrol log_priority=".

Udev_log= "err"

Udev_log: the level at which syslog logs. The default value is err. If changed to info or debug, lengthy udev logs will be recorded.

In fact, in RHEL5.3, in addition to the parameter udev_log listed in the configuration file, Linux users can also modify the parameters udev_root and udev_rules (please refer to the "RHEL4.8 udev configuration file" above), but these two parameters are not recommended to be modified, so they are not shown in udev.conf.

It can be seen that there are a lot of changes in this version of udev.conf: syslog records udev logs by default, and Linux users can only modify the level of logs (err, info, degub, etc.); the permissions of devices cannot be set in udev.conf, but in rule files (* .rules).

Set permissions for device files through udev

In the udev of RHEL4.8, the permissions of the device are set through the permissions file.

Listing 5. Permissions file for udev under RHEL4.8

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

[root@HOST_RHEL4 ~] # cat / etc/udev/permissions.d/50-udev.permissions

……

# disk devices

Hd*:root:disk:0660

Sd*:root:disk:0660

Dasd*:root:disk:0660

Ataraid*:root:disk:0660

Loop*:root:disk:0660

Md*:root:disk:0660

Ide/*:root:disk:0660

Discs/*/*:root:disk:0660

Loop/*:root:disk:0660

Md/*:root:disk:0660

# tape devices

Ht*:root:disk:0660

Nht*:root:disk:0660

Pt [0-9] *: root:disk:0660

Npt*:root:disk:0660

St*:root:disk:0660

Nst*:root:disk:0660

……

The permissions file of udev in RHEL4.8 sets permissions and ownership for all commonly used devices. If any devices are not set permissions by the permissions file, udev sets permissions for these devices according to the default permission limits in udev.conf. Due to space constraints, the above figure shows only a portion of the udev permissions file, which sets permissions and ownership for all disk and tape devices that may be connected.

In the udev of RHEL5.3, there is no permission file, and all permissions are set through the rule file (* .rules), which is described in the following rule file configuration process.

Rules and rule files for udev

The rules file is the most important part of udev and is stored under / etc/udev/rules.d/ by default. All rule files must have the suffix ".rules". RHEL has default rule files that generate not only kernel device names for devices, but also highly identifiable symbolic links. For example:

one

two

[root@HOST_RHEL5 ~] # ls / dev/disk/by-uuid/

16afe28a-9da0-482d-93e8-1a9474e7245c

However, these link names are long and not easy to call, so custom rule files are usually needed to produce easy-to-use and highly identifiable device files or symbolic links.

In addition, some applications also generate symbolic links that are easy to call under / dev/. For example, the rule 40-multipath.rules generates the following symbolic link for the disk:

one

two

[root@ HOST_RHEL5 ~] # ls / dev/mpath/*

/ dev/mpath/mpath0 / dev/mpath/mpath0p1 / dev/mpath/mpath0p2

Udev queries all rule files in alphabetical order of the rule file name, and then manages its device files or file links for devices that match the rules. Although udev does not stop parsing subsequent rule files because a device matches a rule, the order of parsing is still important. In general, it is recommended that the rule file you want be parsed first. For example, create a file called / etc/udev/rules.d/10-myrule.rules and write your rules to it so that udev will parse to your file before parsing the system's default rule file.

The udev rules file in RHEL5.3 is more complete than that in RHEL4.8. Limited by space, and in order not to confuse everyone, this article will not explain the rule files in RHEL4.8 in detail. The following configuration and examples of rule files are carried out on RHEL5.3. If you need to configure the udev rules file of RHEL4, you can first refer to the configuration process of RHEL5.3 below, and then query the user's manual (man udev) in RHEL4 for configuration.

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. Here is a simple rule:

Listing 6. A simple example of key-value pairs

one

KERNEL== "sda", NAME= "my_root_disk", MODE= "0660"

KERNEL is the matching key, and NAME and MODE are the assignment keys. This rule means that if there is a device whose kernel device name is sda, the condition takes effect, performing the following assignment: generate a device file named my_root_disk under / dev and set the permissions of the device file to 0660.

Through this simple rule, you should have an intuitive understanding of the udev rules. But 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.

All operators of the udev rule in RHEL5.3:

"=": compare keys and values. If equal, the condition is satisfied.

"! =": compare keys and values. If not, the condition is satisfied.

"=": assign a key to it

"+ =": assign a value to a key that represents multiple entries.

": =": assign a value to a key and reject all subsequent changes to that key. The goal is to prevent subsequent rule files from assigning values to the key.

Match key of udev Rule in RHEL5.3

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

KE RNEL: kernel device name, for example: sda, cdrom.

DEVPATH: the devpath path of the device.

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

BUS: the bus name of the device in devpath, for example: usb.

DRIVER: the device driver name of the device in devpath, for example: ide-cdrom.

ID: the identification number of the device in devpath.

SYSFS {filename}: the contents of the device's properties file "filename" under the device's devpath path.

For example: SYSFS {model} = = "ST936701SS" indicates that if the model of the device is ST936701SS, the device matches the match key.

In a rule, you can set up to five matching keys for SYSFS.

ENV {key}: environment variable. In a rule, you can set up to five matching keys for environment variables.

PROGRAM: invokes external commands.

RESULT: the result returned by the external command PROGRAM. For example:

one

PROGRAM== "/ lib/udev/scsi_id-g-s $devpath", RESULT== "35000c50000a7ef67"

Call the external command / lib/udev/scsi_id to query the SCSI ID of the device, and if the return result is 35000c50000a7ef67, the device matches the match key.

The important assignment key of udev in RHEL5.3

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.

The value of udev and callable replacement operator in RHEL5.3

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.

The result returned by $result,% c: PROGRAM.

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

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

$tempnode,% N: temporary device name.

%%: symbol% itself.

$: symbol $itself.

Listing 7. An example of a rule that illustrates a replacement operator

one

two

KERNEL== "sd*", PROGRAM= "/ lib/udev/scsi_id-g-s% p",\

RESULT== "35000c50000a7ef67", SYMLINK= "% knight% c"

Execution of this rule: if a kernel device name begins with sd and SCSI ID is 35000c50000a7ef67, a symbolic link "sda_35000c50000a7ef67" is generated for the device file.

Examples of making udev rules and querying device information:

How to find the information (attributes) of a device to make udev rules:

When we set rules for a specified device, we first need to know the properties of the device, such as the serial number of the device, disk size, vendor ID, device path, and so on. Usually we can get it in the following ways:

Query the sysfs file system:

As mentioned earlier, sysfs contains a lot of information about devices and drivers.

For example, the SYSFS {size} of the device sda can be obtained through cat / sys/block/sda/size, and the SYSFS {model} information can be obtained through cat / sys/block/sda/device/model.

Udevinfo command:

Udevinfo can query the equipment information in udev database. For example, use udevinfo to query the model and size information of the device sda:

Listing 8. An example of querying device properties through udevinfo

one

two

three

[root@HOST_RHEL5 rules.d] # udevinfo-a-p / block/sda | egrep "model | size"

SYSFS {size} = "71096640"

SYSFS {model} = = "ST936701SS"

Other external commands:

Listing 9. An example of querying disk SCSI_ID through scsi_id

one

two

[root@HOST_RHEL5] # scsi_id-g-s / block/sda

35000c50000a7ef67

Simple rules for udev:

Listing 10. Rules for generating network card device files

one

SUBSYSTEM== "net", SYSFS {address} = = "AA:BB:CC:DD:EE:FF", NAME= "public_NIC"

The rule states that if there is a device whose subsystem is net and the address (MAC address) is "AA:BB:CC:DD:EE:FF", a device file named public_NIC is generated for the device.

Listing 11. Rules for generating symbolic links for disks of a specified size

one

SUBSYSTEM== "block", SYSFS {size} = = "71096640", SYMLINK = "my_disk"

The rule states that if there is a device whose subsystem is block and the size is 71096640 (block), a symbolic link named my_disk is generated for the device file name of the device.

Listing 12. Rules for generating device files for disks with specified serial numbers through external commands

one

two

KERNEL== "sd* [0-9]", PROGRAM== "/ lib/udev/scsi_id-g-s% p",\

RESULT== "35000c50000a7ef67", NAME + = "root_disk%n"

The rule states that if there is a device whose kernel device name starts with sd (disk device) and ends with a number (disk partition), and the SCSI_ID number of the device is queried as "35000c50000a7ef67" through an external command, a device file that begins with root_disk and ends with the kernel number is generated, and the original device file is replaced (if any). For example: generate the device name / dev/root_disk2 and replace the original device name / dev/sda2.

Using this rule, you can maintain the consistency of the system partition name in / etc/fstab without being affected by the driver loading sequence or disk label being broken, resulting in the system partition not being found when the operating system boots.

Other commonly used udev commands:

Udevtest:

Udevtest simulates a run of udev without uevent trigger for a device, and outputs the process of querying the rule file, the behavior executed, and the execution result of the rule file. Udevtest is usually used to debug rule files. The following is an example of udevtest for device sda. Because udevtest scans all rule files (including those that come with the system), it produces lengthy output. To give the reader a clear understanding of udevtest, this example leaves only one rule in the rules directory:

Listing 13. Rules reserved for udevtest

one

two

KERNEL== "sd*", PROGRAM= "/ lib/udev/scsi_id-g-s% p", RESULT== "35000c50000a7ef67",\

NAME= "root_disk%n", SYMLINK= "symlink_root_disk%n"

Listing 14. Execution of udevtest

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

[root@HOST_RHEL5 rules.d] # udevtest / block/sda

Main: looking at device'/ block/sda' from subsystem 'block'

Run_program:'/ lib/udev/scsi_id-g-s / block/sda'

Run_program:'/ lib/udev/scsi_id' (stdout) '35000c50000a7ef67'

Run_program:'/ lib/udev/scsi_id' returned with status 0

Udev_rules_get_name: reset symlink list

Udev_rules_get_name: add symlink 'symlink_root_disk'

Udev_rules_get_name: rule applied, 'sda' becomes' root_disk'

Udev_device_event: device'/ block/sda' already in database,\

Validate currently present symlinks

Udev_node_add: creating device node'/ dev/root_disk', major = '8pm,\

Minor = '050, mode =' 0660, uid = '01, gid =' 0'

Udev_node_add: creating symlink'/ dev/symlink_root_disk' to 'root_disk'

As you can see, udevtest executes the external command scsi_id on sda, and the resulting stdout matches the RESULT in the rule file, so the rule matches. Then (simulate) generate the device file / dev/root_disk and symbolic link / dev/symlink_root_disk and set permissions for them.

Start_udev:

The start_ dev command restarts the udev daemon and re-queries all the rule files in the rules directory for all devices, and then executes the behavior in the matching rules. You usually use this command to make the new rule file take effect immediately:

Listing 15. Execution of start_udev

one

two

[root@HOST_RHEL5 rules.d] # start_udev

Starting udev: [OK]

Start _ udev generally has no standard output, and all udev-related information is set according to the parameters of the configuration file (udev.conf) and recorded by syslog.

Summary:

Udev is an efficient device management tool, and its biggest advantage is to dynamically manage devices and custom device naming rules, so instead of devfs, Linux has become the default device management tool. By reading this article, Linux users can understand the working principle and process of udev, flexibly use udev rule files, and easily manage Linux device files.

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.