Overview:
Linux users often find it difficult to identify the same type of device name, such as Eth0, Eth1, SDA, SDB, and so on. By observing the kernel device names of these devices, users usually know what type of device they are, but they don't know which device they want. For example, in a list of device names that are flooded with local disks and optical disks ( /dev/sd* ), users cannot find a disk with the serial number "35000c50000a7ef67". In this case, Udev can dynamically in the directory to /dev generate their own desired, highly identifiable device files or device links, so as to help users quickly and easily find the required device files.
Udev is a feature in the Linux2.6 kernel that replaces the original DEVFS and becomes the current Linux default device management tool. Udev runs as a daemon, managing the device files under the directory by listening for the uevent that are issued within it /dev . Unlike previous device management tools, Udev runs in user space instead of kernel space (kernel spaces).
As we all know, all the devices in Linux are in the form of device files. In earlier versions of Linux, the /dev directory contained device files for all devices that might appear. It is hard to imagine how Linux users can find matching conditions in these large number of device files. Udev now produces device files only for those devices connected to the Linux operating system. and Udev can create device files that match device properties by defining a udev rule (rule), which can be a kernel device name, a bus path, a vendor name, a model, a serial number, a disk size, and so on.
/dev the device files, so udev only generates device files for connected devices without /dev generating a large amount of empty device files./dev/sda、/dev/hda、/dev/fd so on. Because Udev is running in user space, Linux users can flexibly produce highly identifiable device filenames, such as, and so on, through custom rules files /dev/boot_disk、/dev/root_disk、/dev/color_printer .The following flowchart shows the process of udev adding/removing device files.
Figure 1. Udev Workflow Flowchart: Related terms:/dev/ can be used by applications to interact with device drivers. It is not a special area for equipment files, equipment nodes or equipment special files.(/sys) . It exports device and driver information from the kernel's device module to user space (userspace). From this file system, Linux users can get the properties of many devices.(/sys) , which contains the device's properties file. Most of the commands in Udev are for Devpath operations. For example:SDA 's devpath is /block/sda , Sda2 's Devpath is /block/sda/sda2 .Back to top of page
How to configure and use UdevThe following sections describe the configuration and use of Udev in RHEL4.8 and RHEL5.3, respectively:
Download and install UdevStarting with Fedora3 and Red Hat Enterprise4, Udev is the default Device management tool that does not require additional download and installation.
Listing 1. Check the version and operation of Udev in RHEL4.8[[Email Protected]_rhel4 dev]# rpm-qa |grep-i udev udev-039-10.29.el4 [[Email Protected]_rhel4 ~]# uname-r
2.6.9-89.ELSMP [[email protected]_rhel4 ~]# ps-ef |grep udev root 21826 1 0 Dec09? 00:00:00 UDEVD
[Email protected]_rhel5 ~]# rpm-qa |grep-i udev udev-095-14.19.el5 [[Email Protected]_rhel5 sysconfig]# Uname-r 2.6.18-128.el5 [[email protected]_rhel5 sysconfig]# ps-ef|grep udev root 5466 1 0 18:32? 00:00:00/sbin/udevd-d
If the Linux user wants to update the UDEV package, it can be downloaded and installed from http://www.kernel.org/pub/linux/utils/kernel/hotplug/.
List of udev configuration files (/etc/udev/udev.conf) 3. RHEL 4. 8 under Udev's configuration file[[Email protected]_rhel4 dev]# cat/etc/udev/udev.conf # udev.conf # The main config file for Udev # # this file Can is 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/" # UD Ev_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 has no # explicit match in the permissions file Default_m Ode= "0600" # Default_owner-set the default owner for all nodes that has no # explicit match in the per Missions file default_owner= "root" # Default_group-Set the default group for all nodes that has 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 from this file:
/dev/ . It is recommended that you do not modify this parameter because many applications invoke device files from this directory by default./dev/.udev.tdb ./etc/udev/rules.d/ ./etc/udev/permissions.d/ .0600/root/root .[[Email Protected]_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 is changed with: "Udevcontrol log_priority=<value>".
udev_log= "Err"
Udev_log: The level ofsyslog logging, and the default value is err. If you change to info or debug, a lengthy udev log will be logged.
In fact, in RHEL5.3, in addition to the parameters listed in the configuration file udev_log , Linux Users can also modify the parameters Udev_root and Udev_rules(refer to the " RHEL4.8 udev configuration File "), but these 2 parameters are not recommended to modify, so it is not shown in the udev.conf.
It can be seen that the version of the udev.conf change is not small:syslog By default will record Udev logs, Linux users can only modify the log level (err, info, degub, etc.), the device's permissions can not be set in the udev.conf, Instead, it is set in the rules file (*.rules).
Setting permissions for device files through UdevIn RHEL4.8 Udev, the permissions of the device are set through the permissions file.
Listing 5. Permissions file for Udev under RHEL4.8[Email protected]_rhel4 ~]# cat/etc/udev/permissions.d/50-udev.permissions ... # disk devices hd*:root:disk:0660< c1/>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:0 660 npt*:root:disk:0660 st*:root:disk:0660 nst*:root:disk:0660 ...
RHEL4.8. Udev's permissions file will set permissions and ownership for all commonly used devices, and if a device does not have permissions set by the permission file, Udev will set the permissions for those devices according to the default permission values in Udev.conf. Due to space limitations, only part of the Udev permissions file is shown, which is divided into the 置了 permissions and ownership of all possible connected disk devices and tape devices.
While in RHEL5.3 Udev, there is no permission file, all permissions are set by the rules file (*.rules) , in the following rule file configuration process will be introduced.
The rule file is the most important part of Udev, which is stored /etc/udev/rules.d/ under the default. All rule files must have " .rules " as the suffix name. RHEL has default rule files, which generate not only kernel device names for devices, but also symbolic links that are highly identifiable. For example:
[Email protected]_rhel5 ~]# Ls/dev/disk/by-uuid/ 16afe28a-9da0-482d-93e8-1a9474e7245c
However, these link names are long and not easy to invoke, so custom rule files are often required to produce easy-to-use and highly identifiable device files or symbolic links.
In addition, some applications /dev/ create symbolic links that make it easy to invoke. For example, rule 40-multipath.rules produces the following symbolic link for the disk:
[Email protected] Host_rhel5 ~]# ls/dev/mpath/* /dev/mpath/mpath0 /dev/mpath/mpath0p1 /dev/mpath/ Mpath0p2
Udev queries all rule files alphabetically by the rule file name, and then manages their device files or file links for devices that match the rules. Although Udev does not stop parsing the subsequent rules files because one device matches a rule, the order of resolution is still important. In general, it is recommended that the rule file you want is parsed first. For example, create a /etc/udev/rules.d/10-myrule.rules file named and write your rules to the file so that udev resolves to your file before parsing the system's default rule file.
RHEL5.3 's Udev rules file is more perfect than RHEL4.8. Subject to the limitations of space, but also in order not to confuse everyone, this article will not be RHEL4.8 in the rules of the document in detail, the following about the rule file configuration and examples are on the RHEL5.3. If you need to configure RHEL4 's Udev rules file, you can refer to the following RHEL5.3 configuration process, and then query the RHEL4 User manual (man udev) after configuration.
In a rule file, all non-empty lines are treated as a rule except for lines (comments) that begin with "#", but a rule cannot be extended to multiple rows. Rules are made up of multiple key-value pairs (Key-value pairs) separated by commas, and key-value pairs can be divided into conditional-matching key-value pairs (hereinafter referred to as "match keys ") and assignment key -value pairs (hereinafter referred to as " Assignment key "), a rule can have multiple matching keys and multiple assignment keys. Matching keys are all conditions that match a device's properties, and when a device's properties match all of the matching keys in the rule, the rule is considered to be in effect and then the assignment of the rule is performed according to the contents of the assignment key. The following is a simple rule:
Listing 6. A simple example of key-value pairskernel== "SDA", Name= "My_root_disk", mode= "0660"
KERNEL is the matching key, and NAME and MODE are the assignment keys. This rule means: if there is a device with the kernel device name SDA, then the condition takes effect, perform the following assignment: /dev under the name my_root_disk of a device file, and set the permissions of the device file to 0660.
With this simple rule, you should have an intuitive understanding of udev rules. But it can be confusing why KERNEL is a matching key, and NAME and MODE are assignment keys? This is determined by the middle operator (operator).
The operator is a matching key only if it is "= =" or "! =", and is an assignment key if it is a different operator.
" = = ": Compare keys, values, if equal, the condition is met;
"! = ": Compare key, value, if not equal, the condition satisfies;
" = ": Assigns a value to a key;
" + = " : Assigns a value to a key that represents multiple entries.
": = ": Assigns a value to a key and rejects any subsequent changes to the key. The goal is to prevent subsequent rules files from assigning a value to the key.
action : Event (uevent) behavior, 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: SDA subsystem is block.
bus : The bus name of the device in the Devpath, for example: USB.
DRIVER : Device driver name for device in Devpath, for example: Ide-cdrom.
ID : The identification number of the device in the Devpath.
Sysfs{filename} : The contents of the device's properties file "FileName" under the Devpath path of the device.
For example: sysfs{model}== "st936701ss" means that if the device's model number is ST936701SS, the device matches the matching key .
In one rule, you can set the match key for up to five SYSFS.
Env{key} : Environment variable. In one rule, you can set a matching key for up to five environment variables.
program : Calls an external command.
result : The return result of the external command program. Example:
program== "/lib/udev/scsi_id-g-S $devpath", result== "35000c50000a7ef67"
Calling external command /lib/udev /scsi_id queries the device's SCSI ID, and if the returned result is 35000c50000a7ef67, the device matches the matching key .
NAME : The /dev device file name that is generated under. Only the first assignment of the name of a device takes effect, and then the matching rule is ignored for the name assignment behavior of the device. If no rules are assigned to the name of the device, Udev uses the kernel device name to generate the device files.
SYMLINK: /dev/ generates a symbolic link for the next device file. Because Udev can only produce one device file for a device, it is recommended to use symbolic links in order not to overwrite files produced by the system's default Udev rules.
OWNER, GROUP, MODE : set permissions for the device.
Env{key}: Import an environment variable.
The keys and operations in key-value pairs are nonalphanumeric, and the value is the last. Linux users are free to customize the values of Udev rules files. For example: my_root_disk, my_printer . You can also refer to the following substitution operators:
$kernel,%k: The device's kernel device name, for example: SDA, CDROM.
$number,%n: The kernel number of the device, for example: Sda3 The kernel number is 3.
$devpath,%p : The devpath path of the device.
$id,%b : The ID number of the device in the Devpath .
$sysfs {file},%s{file} : The contents of the file in the Sysfs of the device. 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 : The major number of the device.
$minor%m : The minor number of the device.
$result,%c : The result of the program return.
$ Parent ,%P: The device file name of the parent device.
$root,%r : The value of Udev_root, which is by default /dev/ .
$tempnode,%N : temporary device name.
%% : symbol% itself.
$$ : the symbol $ itself.
Listing 7. Example of rules explaining substitution operatorskernel== "sd*", program= "/lib/udev/scsi_id-g-S%p", result== "35000c50000a7ef67", symlink= "%k_%c"
Execution of the rule: if a kernel device name starts with SD and the SCSI ID is 35000c50000a7ef67 , a symbolic link "sda_35000c50000a7ef67" is generated for the device file.
Back to top of page
Develop UDEV rules and query device information examples:How to find information (attributes) for a device to develop UDEV rules:
When we set rules for a given device, we first need to know the properties of the device, such as the serial number of the device, the size of the disk, the vendor ID, the device path, and so on. Usually we can obtain the following methods:
As explained earlier, the SYSFS contains a lot of information about the device and the driver.
For example: Device SDA Sysfs{size} can be obtained by cat /sys/block/sda/size getting; Sysfs{model} information can be cat /sys/block/sda/device/model obtained.
Udevinfo can query device information in the Udev database. For example: Use Udevinfo to query the model and size information of the device SDA:
Listing 8. Example of querying device properties via Udevinfo[Email protected]_rhel5 rules.d]# udevinfo-a-P/BLOCK/SDA | Egrep "Model|size" sysfs{size}== "71096640" sysfs{model}== "St936701ss "[Email protected]_rhel5 ~]# scsi_id-g-S/BLOCK/SDA 35000c50000a7ef67
Simple Rules for Udev:
Listing 10. Rules for generating network card device filessubsystem== "NET", sysfs{address}== "AA:BB:CC:DD:EE:FF", name= "Public_nic"This rule means that if the subsystem for the device 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 that produce symbolic links for disks of a specified sizesubsystem== "Block", sysfs{size}== "71096640", SYMLINK = "My_disk"This rule means that if the subsystem of the device is block and the size is 71096640 (block), a symbolic link named My_disk is generated for the device's file name.
Listing 12. Rules for generating device files for disks with specified serial numbers through external commandskernel== "sd*[0-9]", program== "/lib/udev/scsi_id-g-S%p", result== "35000c50000a7ef67", NAME + = "root_disk%n"
This rule indicates that if the kernel device name of the device exists that begins with the SD (disk device), ends with a number (disk partition), and queries the device's scsi_id number as "35000c50000a7ef67" with an external command, a core number is generated that begins with Root_disk, and replace the original device file (if it exists). For example, create a device name /dev/root_disk2 and replace the original device name /dev/sda2 .
With this rule, the system partition name can be kept consistent without being affected by /etc/fstab the drive loading order or the disk label being corrupted, causing the system partition to be found when the operating system starts.
Other commonly used Udev commands:
udevtestThe run is simulated once for a device, without the need for a uevent trigger, udev and the process of querying the rule file, the behavior performed, and the execution result of the rule file are output. Typically used udevtest to debug a rule file. The following is an example of a device SDA udevtest . Because udevtest it is scanning all the rules files (including the system's own rules files), it produces verbose output. To make it clear to the reader udevtest , this example retains only one rule in the rules directory:
Listing 14. Udevtest the execution of the processkernel== "sd*", program= "/lib/udev/scsi_id-g-S%p", result== "35000c50000a7ef67", name= "root_disk%n", SYMLINK= " Symlink_root_disk%n "
[Email protected]_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:dev Ice '/BLOCK/SDA ' already in database, validate currently present symlinks udev_node_add:creating device node '/d Ev/root_disk ', major = ' 8 ', minor = ' 0 ', mode = ' 0660 ', uid = ' 0 ', gid = ' 0 ' udev_node_add:creating symlink '/dev/sym Link_root_disk ' to ' Root_disk '
As you can see, the udevtest external command is executed against SDA scsi_id , and the resulting stdout matches the result in the rule file, so the rule matches. The device files and symbolic links are then generated (simulated) /dev/root_disk /dev/symlink_root_disk , and permissions are set for them.
start_ dev Command restarts the udev daemon and re-queries all the rule files under the Rules directory for all devices, and then executes the behavior in the matching rules. This command is typically used to make the new rule file effective immediately:
[[Email Protected]_rhel5 rules.d]# Start_udev starting udev: [ OK ]
start_udev一般There is no standard output, all Udev related information is udev.conf) recorded by the syslog according to the configuration file (parameter setting).
Use Udev to efficiently and dynamically manage Linux device files
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
