udev的rules定制和调试

https://www.jianshu.com/p/39d520530539

 

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选项很有必要,打印出本次热插拔事件的一些属性

 

 
 

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

比如:

KERNEL[1122.847979] change  /devices/platform/display-subsystem/drm/card0 (drm)

ACTION=change

DEVPATH=/devices/platform/display-subsystem/drm/card0

SUBSYSTEM=drm

HOTPLUG=1

DEVNAME=/dev/dri/card0

DEVTYPE=drm_minor

SEQNUM=5241

MAJOR=226

MINOR=0

rules文件对于规则:

SUBSYSTEM=="drm", ACTION=="change", ENV{HOTPLUG}=="1", RUN+="/usr/local/bin/drm-hotplug.sh

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

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

 

 
 
 
 

方法2:

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

比如:

SUBSYSTEM=="drm", ACTION=="add", KERNEL=="card[0-9]*-HDMI-*", RUN+="/usr/local/bin/drm-add.sh $kernel $devpath $sysfs{status}"

参考信息:

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的内存才能准确区分事件。



作者:心远气自静
链接:https://www.jianshu.com/p/39d520530539
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
posted @ 2022-04-22 11:34  jiftle  阅读(2014)  评论(0编辑  收藏  举报