LINUX Udev机制介绍及简单调试

• 使用info查看设备属性

yanyg@pc:~$ udevadm info -a -x /dev/sg0

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/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0':
    KERNEL=="sg0"
    SUBSYSTEM=="scsi_generic"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0':
    KERNELS=="0:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"

• 在/etc/udev/rules.d/下放置特化rules文件（文件扩展名为rules）。例如：

yanyg@pc:~$ cat /etc/udev/rules.d/50-test-sg.rules
SUBSYSTEM=="scsi_generic", KERNEL=="sg[0-9]*", RUN+="/usr/sbin/sg-test.sh $tempnode $kernel"

• 在脚本中处理特定事件：

yanyg@pc:~/org$ cat /usr/sbin/sg-test.sh
#! /bin/bash

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

[ "$ACTION" = "remove" ] && exit 0

LOGGER="logger -t udev[$(cat /proc/uptime | cut -d' ' -f1)] --"

$LOGGER "Hello debug udev, process here"

• 不重启加载新的rules

yanyg@pc:~$ sudo udevadm control --reload

• 测试是否生效

yanyg@pc:~$ sudo udevadm test /sys/class/scsi_generic/sg0
...
28133 strings (230213 bytes), 24413 de-duplicated (197990 bytes), 3721 trie nodes used
RUN '/usr/sbin/sg-test.sh $tempnode $kernel' /etc/udev/rules.d/50-test-sg.rules:1
GROUP 6 /lib/udev/rules.d/50-udev-default.rules:63
...

• 触发特定事件

yanyg@pc:~$ sudo udevadm trigger --subsystem-match=scsi_generic --verbose
/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0

• 触发时的日志输出：

Apr 20 19:06:32 pc udev[729227.64]: Hello debug udev, process here

LINUX通过设备文件的主次设备号与内核建立映射关系。设备文件的维护经历了静态维护、 devfs内核态维护、sysfs+hotplug用户态维护、udev几个阶段。相对比之前，udev使用更少空间，提供更高的弹性、更便捷的设备文件维护。参考udev talk获取更多细节。

优势总结：用户态、动态分配、更小、更便捷。LWN 65197有更多细节描述：

The Problems:

1. A static /dev is unwieldy and big. It would be nice to only show the /dev entries for the devices we actually have running in the system.
2. We are (well, were) running out of major and minor numbers for devices.
3. Users want a way to name devices in a persistent fashion (i.e. "This disk here, must always be called "boot_disk" no matter where in the scsi tree I put it", or "This USB camera must always be called "camera" no matter if I have other USB scsi devices plugged in or not.")
4. Userspace programs want to know when devices are created or removed, and what /dev entry is associated with them.

The constraints:

1. No policy in the kernel!
2. Follow standards (like the LSB)
3. must be small so embedded devices will use it.

So, how does devfs stack up to the above problems and constraints: Problems:

1. devfs only shows the dev entries for the devices in the system.
2. devfs does not handle the need for dynamic major/minor numbers
3. devfs does not provide a way to name devices in a persistent fashion.
4. devfs does provide a deamon that userspace programs can hook into to listen to see what devices are being created or removed.

Constraints:

1. devfs forces the devfs naming policy into the kernel. If you don't like this naming scheme, tough.
2. devfs does not follow the LSB device naming standard.
3. devfs is small, and embedded devices use it. However it is implemented in non-pagable memory.