udev的rules定制和调试

udev的rules定制和调试

在定制项目中，对外设的热插拔的管理基本都在udev/systemd-udev来管理。这里没有对基本的udev使用/rules书写脊贺冲进行介绍。

1. udev的rules可能的位置

/lib/udev/rules.d -- udev默认/预置的rules

/etc/udev/rules.d/ -- 定制的rules， 优先级高于/lib/udev/rules.d，官方建议客户写的樱歼rules都放这里

至于放在哪个位置，自己决定就好，既然你在修改系统就应该知道你在做什么

2. 定制自己的rules

定制热插拔的事件，具体到rules就是：

  1）过滤到正确的udev事件。

  2）指定执行的动作，rules里的“RUN”，通常是脚本（毕竟要完成一个功能，绝大多数场景都不是一个命令能搞定的）

3.到这里就要设计到rules的调试了

  1）如何知道要过滤的是条件？

  2）如何将必要的参数传递给RUN执行的脚本？

方法1:

udevadm monitor -p

-- 监测所以的kernel/udevd的热插拔事件， -p选项很有必要，打印出本次热插拔事件的一些属性

这里就是比较设备插入和拔出时的事件属性的不同，可作为过滤的条件

比如：

rules文件对于规则：

到这里很多时候就能满足要求了，如果还有解决不里的场景，就要进一步修改过滤条件。

man udev里会有绝大部分的关键字的信息（想全部的就只能去撸源码）。

方法2:

通过在RUN指定的脚本里传递参数，来找到设备存在和不存在的属性差异。

比如：

参考信息：

a）、udev 规则的匹配键

ACTION： 事件 (uevent) 的行为，例如：add( 添加设备 )、remove( 删除设备 )。

KERNEL： 内核设备名称，例如：sda, cdrom。

DEVPATH：　  设备的 devpath 路径。

SUBSYSTEM： 设备的子系统名称，例如：sda 的子系统为 block。

BUS： 设备在 devpath 里的总线名称，例如：usb。

DRIVER： 设备在 devpath 里的设备驱动名称，例如：ide-cdrom。

ID： 　 设备在 devpath 里的识别号。

SYSFS{filename}： 设备的 devpath 路径下，设备的属性文件“filename”里的内容。

　例如：SYSFS{model}==“ST936701SS”表示：如果设备的型号为 ST936701SS，则该设备匹配该 匹配键。

　在一条规则中，可以设定最多五条 SYSFS 的 匹配键。

ENV{key}： 　 环境变量。在一条规则中，可以设定最多五条环境变量的 匹配键。

PROGRAM：调用外部命令。

RESULT：   外部命令 PROGRAM 的返回结果。

b）、udev 的重要赋值键

NAME：　在 /dev下产生的设备文件名。只有第一次对某个设备的 NAME 的赋值行为生效，之后匹配的规则再对该设备的 NAME 赋值行为将被忽略。如果没有任何规则对设备的 NAME 赋值，udev 将使用内核设备名称拍则来产生设备文件。

SYMLINK：　 为 /dev/下的设备文件产生符号链接。由于 udev 只能为某个设备产生一个设备文件，所以为了不覆盖系统默认的 udev 规则所产生的文件，推荐使用符号链接。

OWNER, GROUP, MODE：为设备设定权限。

ENV{key}：　导入一个环境变量。

c）、udev 的值和可调用的替换 *** 作符

Linux 用户可以随意地定制 udev 规则文件的值。例如：my_root_disk, my_printer。同时也可以引用下面的替换 *** 作符：

$kernel, %k：设备的内核设备名称，例如：sda、cdrom。

$number, %n：　 设备的内核号码，例如：sda3 的内核号码是 3。

$devpath, %p：　设备的 devpath路径。

$id, %b：设备在 devpath里的 ID 号。

$sysfs{file}, %s{file}：  设备的 sysfs里 file 的内容。其实就是设备的属性值。

$env{key}, %E{key}：　一个环境变量的值。

$major, %M：设备的 major 号。

$minor %m：设备的 minor 号。

$result, %c：PROGRAM 返回的结果。

$parent, %P：    父设备的设备文件名。

$root, %r：  udev_root的值，默认是 /dev/。

$tempnode, %N：临时设备名。

%%：符号 % 本身。

$$：　符号 $ 本身。

对比一下和man里的差别，$sysfs{file}，这个在实际解决问题的时候是很有用的。

这种方法适合调试系统启动的时候对rules的调试，这个过程中是没得udevadmin monitor使用的。（当然，可以尝试自己写一个systemd启动服务，这就涉及到启动的时机、关联、影响，实际 *** 作会比预想的复杂）

这里提两个点：

1. env - 可以是udev事件里的属性（-p打印的）

2. $sysfs{file}, 这里的file就是在系统/sys目录下对应的节点下的文件，有些情况下只能在sysfs的file的内存才能准确区分事件。

/etc/udev/rules.d这个目录存储的是以.rules结束的文件。下面可能有好几个udev规则文件，每一个文件处理一系列规则来帮族槐助udev分配名字给设备文件以保证能被内核识别。规则文拍誉件里的规则有一系列的键/值对组成，键/值对之间用逗号(,)分割。每一个键或者是用户匹配键，或者是一个袭穗段赋值键。匹配键确定规则是否被应用，而赋 值键表示分配某值给该键。这些值将影响udev创建的设备文件。赋值键可以处理一个多值列表。

具体可见：

http://www.cnblogs.com/sopost/archive/2013/01/09/2853200.html

方法/步骤

使用“cd /etc/udev/rules.d/”命令，进入规则目录。

使用“cat 70-persistent-担饥曹渴丨韭查血肠摩net.rules”命令，查看网卡设备名称和mac地址的对应关系。

如果在“70-persistent-net.rules”文件中发现了，某个设备名称和mac地址不对应的现象，可以将此文件直接删除，然后重启系统，就可以坦让了。

由于没有虚拟旁旦机无法复现运信扰网卡设备名称和mac地址不对应的情况，就不截图了。

---