Use of udev and mdev under linux

There are three kinds of device file systems under linux: devfs, udev and mdev.

1, devfs

devfs was introduced by Linux 2.4 kernel, which was highly praised by many engineers. Its emergence enables device drivers to manage their own device files independently.

Specifically, devfs has the following advantages:

1. You can create a device file in the / dev directory during device initialization through the program, and delete it when uninstalling the device.

2. The device driver can specify the device name, owner and permission bit, and the user space program can still modify the owner and permission bit.

3. It is no longer necessary to assign the primary device number and processing secondary device number to the device driver.

devfs also has some disadvantages:

1. Uncertain device mapping.

2. There are not enough primary / secondary equipment numbers.

3. There are too many files in the / dev directory.

4. Naming is not flexible enough.

5. Kernel space exists.

2, The difference between udev and devfs

In the Linux 2.6 kernel, devfs was considered an outdated method and was eventually abandoned and replaced by udev. Several reasons for udev replacing devfs:

1. The work done by devfs is believed to be completed in user mode.

2. devfs found some bug s that could not be fixed.

3. The maintainers and authors of devfs are disappointed with it and have stopped maintaining the code.

4. udev works completely in user mode, using the hot plug events sent by the device to join or remove the kernel. During hot plug, the details of the device will be input by the kernel to the sysfs file system located in / sys. The user's permission and the device's permission in the sys control node are used to complete the work.

5. Because udev dynamically updates device files, creates and deletes device files according to the status of hardware devices in the system, only the real devices in the system will be included in the / dev directory after using udev.

6. Another significant difference between devfs and udev is that with devfs, when a nonexistent / dev node is opened, devfs can automatically load the corresponding driver, while udev cannot. This is because udev designers believe that Linux should load the driver module when the device is discovered, not when it is accessed. The designer of udev believes that the function of automatically loading the driver when opening the / dev node provided by devfs is redundant for a computer with correct configuration. All devices in the system should generate hot plug events and load appropriate drivers, and udev can notice this and create corresponding device nodes for it.

3, udev

Udev is a user space program that uses uevent mechanism to deal with hot plug problems. Udev is based on netlink mechanism. It runs a daemon program udevd when the system starts. It performs the corresponding hot plug actions by listening to the uevent sent by the kernel, including creating / deleting device nodes, loading / unloading driver modules and so on. The netlink mechanism used by udev is highly efficient when there are a large number of uevents, and is suitable for PC.

1. udev profile

The configuration file of udev is / etc / udev / udev conf. The contents are as follows:

udev_root="/dev/"
udev_rules="/etc/udev/rules.d"
udev_log="err"

udev_rules represents the directory where udev rules are stored. This directory stores Rules ends the file. The file name of these rule files usually starts with two numbers, which indicates the order in which the system applies the rule. For example: 96 disk_ mounts. rules,98-disk_umounts.rules.

2. udev rule

udev rule files are based on behavior units. The lines beginning with "#" represent comment lines, and the other lines represent a rule. The rules are divided into two parts: matching and assignment. Both parts have their own keywords.

udev key / value pair operator:

Operator matching or assignment interpretation
----------------------------------------
==Match equality comparison
!= Matching inequality comparison
=Assignment: assign a specific value to the key, which can override the previous assignment.
+=Assignment: append a specific value to an existing key
: = assignment - assign a specific value to the key, which cannot be overwritten by subsequent rules.

Matching key of udev rule:

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

KERNEL: KERNEL device name, for example: sda, cdrom.

devpath: devpath path of the device.

SUBSYSTEM: the name of the SUBSYSTEM 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 name of the device DRIVER in devpath, for example: ide CDROM.

ID: the identification number of the device in devpath.

SYSFS{filename}: the contents in the device property file "filename" under the devpath path of the device.

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

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

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

PROGRAM: call external commands.

RESULT: the returned RESULT of the external command PROGRAM. For example:

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

Call the external command / lib/udev/scsi_id query the SCSI ID of the device. If the returned result is 35000c5000a7ef67, the device matches the matching key.

Important assignment keys of udev:

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

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

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

ENV{key}: import an environment variable.

RUN: execute the program of the device.

udev value and callable replacement operator:

Linux users can customize the values of udev rule files at will. For example: my_root_disk, my_printer. You can also refer to the following replacement operators:

$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: devpath path of the device.

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

$sysfs {file},% s {file}: the contents of file in sysfs of the device. In fact, it is the attribute 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,% C: the result returned by PROGRAM.

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

$root, %r: udev_ The default value of root is / dev /.

$tempnode,% n: temporary device name.

%%: the symbol% itself.

$$: the symbol $itself.

3. udev example

96-disk_ mounts. The rules are as follows:

# sdisk case a
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{vendor}=="Generic ", ATTRS{scsi_level}=="3" , ACTION=="add" , \
RUN+="/usr/local/bin/sdisk_mounts.sh %k %n -k"
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{vendor}=="Generic ", ATTRS{scsi_level}=="0" , ACTION=="add" , \
RUN+="/usr/local/bin/sdisk_mounts.sh %k %n -k"

# sdisk case b
KERNEL=="sd??[0-9]", SUBSYSTEM=="block", ATTRS{vendor}=="Generic ", ATTRS{scsi_level}=="3" , ACTION=="add" , \
RUN+="/usr/local/bin/sdisk_mounts.sh %k %n -k"
KERNEL=="sd??[0-9]", SUBSYSTEM=="block", ATTRS{vendor}=="Generic ", ATTRS{scsi_level}=="0" , ACTION=="add" , \
RUN+="/usr/local/bin/sdisk_mounts.sh %k %n -k"

# other disk case a
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{vendor}!="Generic ", ACTION=="add" , \
RUN+="/usr/local/bin/confirm_disk_and_mounts.sh %k %n"
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{vendor}!="Generic ", ACTION=="add" , \
RUN+="/usr/local/bin/confirm_disk_and_mounts.sh %k %n"

# other disk case b
KERNEL=="sd??[0-9]", SUBSYSTEM=="block", ATTRS{vendor}!="Generic ", ACTION=="add" , \
RUN+="/usr/local/bin/confirm_disk_and_mounts.sh %k %n"
KERNEL=="sd??[0-9]", SUBSYSTEM=="block", ATTRS{vendor}!="Generic ",ACTION=="add" , \
RUN+="/usr/local/bin/confirm_disk_and_mounts.sh %k %n"

4, mdev

Mdev is a simplified version of udev that comes with busybox. Mdev is also a user space program that uses uevent mechanism to deal with hot plug problems. Mdev is based on uevent_helper mechanism, which modifies uevnet in the kernel at system startup_ The helper variable (by writing / proc/sys/kernel/hotplug) has a value of "/ sbin/mdev". In this way, uevent will be called when the kernel generates uevent_ The user level program referred to by helper, that is, mdev, performs the corresponding hot plug action. Uevent used by mdev_ The helper mechanism is simple to implement and suitable for embedded systems.

Mdev in busybox Txt document details the use of mdev. Example:

mount -t tmpfs tmpfs /dev  -o size=64k,mode=0755
mkdir /dev/pts /dev/shm
chmod 777 /dev/shm
mount -t devpts devpts /dev/pts
touch /dev/mdev.seq
echo "/sbin/mdev" > /proc/sys/kernel/hotplug
mdev -s

1. mdev configuration file

The configuration file of mdev is / etc / mdev conf. The contents are as follows:

console 0:0 0600 
cpu_dma_latency 0:0 0660 
fb0:0 44 0660 
full 0:0 0666 
initctl 0:0 0600 
ircomm[0-9].* 0:20 0660 
kmem 0:15 0640 
kmsg 0:0 0660 
log 0:0 0666 
loop[0-9].* 0:6 0640 
mem 0:15 0640 
network_latency 0:0 0660 
network_throughput 0:0 0660 
null 0:0 0666 
port 0:15 0640 
ptmx 0:5 0666 
ram[0-9].* 0:6 0640 
random 0:0 0666 
sd[a-z]* 0:6 0660
sd[a-z]*[0-9]* 0:6 0660  */etc/mdev/automountusbstorage.sh
tty 0:5 0666 
tty.* 0:0 0620 
urandom 0:0 0666 
sda* 0:6 0660
sd[a-z][0-9] 0:6 0660 */etc/mdev/automountusb.sh
vcs.* 0:5 0660 
zero 0:0 0666 

hwrng 10:183 0660 =hw_random
pcm.* 0:0 0660 =snd/ 
control.* 0:0 0660 =snd/ 
timer 0:0 0660 =snd/ 

event.* 0:0 0660 =input/ @/etc/mdev/find-touchscreen.sh
mice 0:0 0660 =input/ 
mouse.* 0:0 0660 =input/

tun[0-9]* 0:0 0660 =net/

mmcblk[0-9]*        0:6     660 */etc/mdev/autoformat.sh 
mmcblk[0-9]*p[0-9]* 0:6     660 */etc/mdev/automountsdcard.sh

2. mdev rule

The format is as follows:

<device regex> <uid>:<gid> <octal permissions> [<@$*><cmd>]
@ executed after node creation
$executed before deleting node
* run both after creation and before deletion

3. mdev example

automountusb. The contents are as follows:

#!/bin/sh

usb_mount="/media/usb"
if [ -d $usb_mount ]
then
    echo "$usb_mount exist!"
else
    mkdir -p $usb_mount
fi

umount_usb()
{
    grep -qs "^/dev/$1" /proc/mounts
    [ $? -eq 0 ] && umount $usb_mount
}

mount_usb()
{
    if [ `fsck.ext4 -a /dev/$1` -a `fsck.fat -a /dev/$1` ]
    then
        echo "Error: Unsupported FS!!!"
        exit 1
    fi
    mount -t auto "/dev/$1" "$usb_mount"
    [ $? -ne 0 ] && echo "mount /dev/$1 fail!" && exit 1
}

case "${ACTION}" in
    add|"")
        umount_usb ${MDEV}
        mount_usb ${MDEV}
        ;;
    remove)
        umount_usb ${MDEV}
        ;;
esac

 

 

reference material:

https://blog.csdn.net/qq_31505483/article/details/52866037

https://www.cnblogs.com/linhaostudy/archive/2018/07/08/9279041.html

https://www.cnblogs.com/fah936861121/p/6496608.html

Tags: Linux

Posted by glennn3 on Sat, 21 May 2022 07:48:07 +0300