什么是Udev

Udev到底是个什么鬼？
简单讲：udev负责在用户空间，根据用户设置的规则，在监测到设备被插入后，在/dev/下自动创建并命名设备文件节点（实际上只能做一个已存在节点的链接文件），也可以自动设置设备属性。

//经常会遇到这种情况，在/sys/目录下的event0、event1、event2等文件跟/dev/input/event的设备文件对不上，不理解他们到底是如何对应的。没错，是udev在负责这个工作。

上面这句话的理解是错误的，/dev下的设备文件，大部分是在驱动程序中被创建出来的（使用device_creat函数），而udev只能添加链接文件和更改设备文件的相关属性。

附上一个链接地址：http://www.cnblogs.com/hnrainll/archive/2011/06/24/2088577.html 这篇文章介绍了内核驱动是如何创建/dev下的设备节点的

2.4版本内核使用devfs来负责完成这项工作，2.6版本后这部分内容被认为应该运行在用户空间，且devfs也暴漏出了很多不可修复的bug，所以udev应运而生。

Devfs和udev的区别主要有以下两点：

1、devfs运行在内核空间（使用devfs_register等API在内核空间注册设备节点）；而udev运行在用户空间、

2、当用户访问/dev下的某个节点时，devfs会自动加载对应的驱动；而udev则并不负责自动加载驱动的工作（2.6版本内核，驱动是在设备被插入/移除时被加载/卸载的，而不是设备被访问时就加载驱动）。

Udev的工作机制是什么？

Udev完全工作在用户空间，当一个设备被插入或者移除时，内核会通过netlink套接字发送设备详细信息到用户空间，udev获取到设备信息，根据信息内容在/dev下创建并命名设备节点。

既然udev创建节点的时机是设备被插入的时候，那么就出现一个问题：

冷插拔的设备怎么办

由于冷插拔的设备开机时就已经存在，在udev启动前已经被插入。针对这种情况，sysfs下的设备都存在uevent文件，向该文件写一个“add”,内核会重新发送netlink，之后udev就可以收到设备的详细信息了，从而创建/dev下对应的设备节点。

Udev的规则文件

1. 配置文件
   udev的配置文件位于 /etc/udev/ 和 /lib/udev/ （ # 开头的是注释）
   udev 的主配置文件是 /etc/udev/udev.conf。 它包含一套变量，允许用户修改 udev 默认值。可以设置的变量如下：
   udev_root 设备目录，默认是/dev
   udev_log 日志等级（表示严重程度），跟 syslog 一致，例如： err, info, debug。

2. 规则文件
   udev的规则文件一般位于 /lib/udev/rules.d/，也可以位于 /etc/udev/rules.d/
   规则文件是按照字母顺序处理的，不管放在哪个目录。对于相同名字的规则文件， /etc/udev/rules.d 比 /lib/udev/rules.d 优先。
   规则文件必须以 .rules 作为扩展名，否则不被当作规则文件。
   规则文件的每一行都是 key=value 格式。 key 有两个类型：1）匹配型 key 2）赋值型 key
   当所有匹配型 key 都匹配时，该规则即被采用，赋值型 key就会获得相应的值。
   当规则匹配时，可以重命名网络接口， 创建到设备节点的符号链或运行一个指定程序来处理该事件。
   一条规则由多个key=value 组成，以英文逗号隔开。 每个key 有一个操作，取决于操作符，有效的操作符如下：
   == 比较是否相等
   != 比较是否不相等
   = 给一个key 赋值。表示一个列表的key会被重置，并且把这个唯一的值传给它
   += 将一个值增加到key中
   := 将一个值传给一个key，并且不允许再修改这个key。

3. 匹配型KEY
   下面的 key 可以匹配设备属性，部分 key 也可用于匹配 sysfs 中的父设备属性，不仅仅是产生事件的那个设备。
   如果在一个规则中，有多个key匹配了一个父设备，则这些 key必须匹配同一个父设备：
   ACTION 匹配事件的动作名
   DEVPATH 匹配事件的设备devpath
   KERNEL 匹配事件的设备名
   NAME 匹配网络接口或者设备节点的名字。NAME 只有在前面的规则赋值之后才可以使用。
   SYMLINK 匹配设备节点符号链的名字。SYMLINK 只有在前面的规则赋值之后才可以使用。可以有多个 symlinks，只需要匹配一个。
   SUBSYSTEM 匹配设备子系统
   DRIVER 匹配设备的驱动名。只对绑定到一个驱动的设备有用。
   ATTR { filename } 匹配事件设备的sysfs 属性。
   KERNELS 向上搜索devpath，直到找到一个匹配的设备名
   SUBSYSTEMS 向上搜索devpath，直到找到一个匹配的子系统名
   DRIVERS 向上搜索devpath，直到找到一个匹配的驱动名
   ATTRS{ filename } 向上搜索devpath，直到找到一个含匹配 sysfs 属性的设备
   ENV{ key }
   TAG 设备的 tag
   TEST{octal mode mask} 测试一个文件是否存在，可以指定一个8进制的模式掩码。
   PROGRAM 执行一个程序。如果程序成功返回， key 为 true。设备的属性被放在被执行进程的环境变量中，该程序的输出为 stdout， 可以从 RESULT 这个 key 读取。
   RESULT 匹配最近一次PROGRAM 调用的返回字符串。它应该在 PROGRAM 之后使用

支持一些shell的通配符： * (代表[ 0 个到无穷多个 ]任意字符
? (代表[一定有一个]任意字符)
[ ] (代表[一定有一个在括号内]的字符(非任意字符))

4. 赋值型KEY

下面的key 是赋值型 key：
NAME
SYMLINK
OWNER， GROUP， MODE
ATTR { key }
ENV { key }
TAG
RUN
LABEL GOTO 可以跳到的地方
GOTO 跳到下一个带有匹配名字的 LABEL 处。
IMPORT { type }
WAIT_FOR
OPTIONS
NAME, SYMLINK, PROGRAM, OWNER, GROUP、MODE 和 RUN 这些 field 支持一个简单的、类似于 printf 函数的格式字符串替换。可用的字符替换如下：
$kernel,$kernel)
$number, %n：该设备的内核号码。例如 sda3 的内核号码是 3。
$devpath, %p： 该设备的 devpath
$id, %b：当向上搜索devpath，寻找 SUBSYSTEMS， KERNELS， DRIVERS 和 ATTRS 时，被匹配的设备名字
$driver： 当向上搜索devpath，寻找 SUBSYSTEMS， KERNELS， DRIVERS 和 ATTRS 时，被匹配的驱动名字
$attr { file }, %s { file }： 一个被发现的设备的sysfs 属性的值。如果该设备没有该属性，且前面的 KERNELS, SUBSYSTEMS, DRIVERS或 ATTRS 测试选择的是一个父设备，那么就用父设备的属性。如果属性是一个符号链，符号链的最后一个元素作为返回值。
$env { key }, %E { key }： 一个设备属性值
$major, %M： 该设备的内核主号码
$minor, %m： 该设备的内核次号码
$result, %c： 由 PROGRAM 调用的外部程序返回的字符串。如果这个字符串包含空格，可以用 %c{N} 选中第N个字段。如果这个数字N，后面有一个 + 字符， 则表示选中从这个字段开始的所有后面的字符串 %c { N + }
$parent, %p：父设备的节点名字
$name：设备节点的名字，用一个空格作为分隔符。该值只有在前面的规则赋值之后才存在，或者是remove事件。
$links：当前符号链的列表，用空格隔开。该值只有在前面的规则赋值之后才存在，或者是remove事件。
$root, %r：udev_root 的值
$sys, %S：sysfs 挂载点
$tempnode, %N：在真正的设备节点创建之前，创建的一个临时的设备节点的名字，这个临时设备节点供外部程序使用。
$${：}^{\prime }$'字符自己
%%： ‘%’ 字符自己

编写规则文件时可以参考sysfs下设备已经存在的信息，使用udevadm命令可查看内核上送的设备详细信息。

比如：udevadm info–a –p /sys/devices/soc0/fb.25/graphics/fb0

就可以查看ttyS0的详细信息，然后根据已经存在信息，重新设置规则文件，上面命令的输出如下：

Udevadm info starts with the device specified by the devpath and then

walks up the chain of parent devices. It prints for every device

found, all possible attributes in the udev rules key format.

A rule to match, can be composed by the attributes of the device

and the attributes from one single parent device.

looking at device’/devices/soc0/fb.25/graphics/fb0’:

KERNEL=="fb0"

SUBSYSTEM=="graphics"

DRIVER==""

ATTR{pan}=="0,0"

ATTR{name}=="DISP4BG"

ATTR{mode}==“U:1024x768p-59”

ATTR{console}==""

ATTR{blank}==""

ATTR{modes}==“U:1024x768p-59”

ATTR{state}=="0"

ATTR{fsl_disp_property}==“2-layer-fb-bg”

ATTR{bits_per_pixel}=="16"

ATTR{cursor}==""

ATTR{rotate}=="0"

ATTR{stride}=="2048"

ATTR{fsl_disp_dev_property}==“ldb”

ATTR{virtual_size}==“1024,768”

looking at parent device’/devices/soc0/fb.25’:

KERNELS=="fb.25"

SUBSYSTEMS==“platform”

DRIVERS==“mxc_sdc_fb”

looking at parent device’/devices/soc0’:

KERNELS=="soc0"

SUBSYSTEMS=="soc"

DRIVERS==""

ATTRS{revision}==“1.5”

ATTRS{machine}=="ReciFreescale i.MX6 Quad SABRE Smart Device Board"

ATTRS{family}=="Freescalei.MX"

ATTRS{soc_id}==“i.MX6Q”

原文：https://blog.csdn.net/woyimibayi/article/details/78320915