Linux下udev和mdev详解

/*
* Edison Gao
*/
设备文件系统有devfs,mdev,udev这三种

如果你使用Linux比较长时间了，那你就知道，在对待设备文件这块，Linux改变了几次策略。在Linux早期，设备文件仅仅是是一些带有适当的属性集的普通文件，它由mknod命令创建，文件存放在/dev目录下。后来，采用了devfs, 一个基于内核的动态设备文件系统，他首次出现在2.3.46内核中。Mandrake，Gentoo等Linux分发版本采用了这种方式。devfs创建 的设备文件是动态的。但是devfs有一些严重的限制，从2.6.13版本后移走了。目前取代他的便是文本要提到的udev－－一个用户空间程序。

目前很多的Linux分发版本采纳了udev的方式，因为它在Linux设备访问，特别是那些对设备有极端需求的站点(比如需要控制上千个硬盘)和热插拔设备(比如USB摄像头和MP3播放器)上解决了几个问题。下面我我们来看看如何管理udev设备。
实际上，对于那些为磁盘，终端设备等准备的标准配置文件而言，你不需要修改什么。但是，你需要了解udev配置来使用新的或者外来设备，如果不修改配置， 这些设备可能无法访问，或者说Linux可能会采用不恰当的名字，属组或权限来创建这些设备文件。你可能也想知道如何修改RS－232串口，音频设备等文件的属组或者权限。这点在实际的Linux实施中是会遇到的。

不使用devfs的原因
不确定的设备映射。特别是那些动态设备，比如USB设备，设备文件到实际设备的映射并不可靠和确定。举一个例子：如果你有两个USB打印机。一个可能称 为/dev/usb/lp0,另外一个便是/dev/usb/lp1。但是到底哪个是哪个并不清楚，lp0,lp1和实际的设备没有一一对应的关系，因为 他可能因为发现设备的顺序，打印机本身关闭等原因而导致这种映射并不确定。理想的方式应该是：两个打印机应该采用基于他们的序列号或者其他标识信息的唯一 设备文件来映射。但是静态文件和devfs都无法做到这点。

*没有足够的主/辅设备号。我们知道，每一个设备文件是有两个8位的数字：一个是主设备号 ，另外一个是辅设备号来分配的。这两个8位的数字加上设备类型(块设备或者字符设备)来唯一标识一个设备。不幸的是，关联这些身边的的数字并不足够。

*/dev目录下文件太多。一个系统采用静态设备文件关联的方式，那么这个目录下的文件必然是足够多。而同时你又不知道在你的系统上到底有那些设备文件是激活的。

*命名不够灵活。尽管devfs解决了以前的一些问题，但是它自身又带来了一些问题。其中一个就是命名不够灵活；你别想非常简单的就能修改设备文件的名字。缺省的devfs命令机制本身也很奇怪，他需要修改大量的配置文件和程序。

*内核内存使用，devfs特有的另外一个问题是，作为内核驱动模块，devfs需要消耗大量的内存，特别当系统上有大量的设备时(比如上面我们提到的系统一个上有好几千磁盘时)

udev的目标是想解决上面提到的这些问题，他通采用用户空间(user-space)工具来管理/dev/目录树，他和文件系统分开。知道如何改变缺省配置能让你之大如何定制自己的系统，比如创建设备字符连接，改变设备文件属组，权限等。

到现在，devfs被认为是过时的方法，已经给抛弃，udev取代了它。

udev和devfs的一个显著的区别在于：采用devfs，当一个并不存在的/dev节点被打开的时候，devfs能自动加载对应的驱动，而udev则不这么做。这是因为udev的设计者认为Linux应该在设备被发现的时候加载驱动模块，而不是当它被访问的时候。udev的设计者认为devfs所提供的打开/dev节点时自动埃及在驱动的功能对于一个配置正确的计算机是多余的。系统中所有的设备都应该产生热拔插事件并加载恰当的驱动，而udev能注意到这点并且为它创建对应的设备节点。

udev配置文件

主要的udev配置文件是/etc/udev/udev.conf。这个文件通常很短，他可能只是包含几行#开头的注释，然后有几行选项：

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

上面的第二行非常重要，因为他表示udev规则存储的目录，这个目录存储的是以.rules结束的文件。每一个文件处理一系列规则来帮助udev分配名字给设备文件以保证能被内核识别。
你的/etc/udev/rules.d下面可能有好几个udev规则文件，这些文件一部分是udev包安装的，另外一部分则是可能是别的硬件或者软件包 生成的。比如在Fedora Core 5系统上，sane-backends包就会安装60-libsane.rules文件，另外initscripts包会安装60-net.rules文 件。这些规则文件的文件名通常是两个数字开头，它表示系统应用该规则的顺序。

规则文件里的规则有一系列的键/值对组成，键/值对之间用逗号(,)分割。每一个键或者是用户匹配键，或者是一个赋值键。匹配键确定规则是否被应用，而赋 值键表示分配某值给该键。这些值将影响udev创建的设备文件。赋值键可以处理一个多值列表。匹配键和赋值键操作符解释见下表：

操作符        匹配或赋值                             解释
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
==             匹配                       相等比较
!=             匹配                       不等比较
=              赋值                       分配一个特定的值给该键，他可以覆盖之前的赋值。
+=             赋值                       追加特定的值给已经存在的键
:=             赋值                       分配一个特定的值给该键，后面的规则不可能覆盖它

这有点类似我们常见的编程语言，比如C语言。只是这里的键一次可以处理多个值。有一些键在udev规则文件里经常出现，这些键的值可以使用通配符(*,?,甚至范围，比如[0-9])，这些常用键列举如下：

ACTION                     一个时间活动的名字，比如add，当设备增加的时候
KERNEL                     在内核里看到的设备名字，比如sd*表示任意SCSI磁盘设备
DEVPATH              内核设备录进，比如/devices/*
SUBSYSTEM              子系统名字，比如sound,net
BUS                     总线的名字，比如IDE,USB
DRIVER                     设备驱动的名字，比如ide-cdrom
ID                       独立于内核名字的设备名字
SYSFS{ value}              sysfs属性值，他可以表示任意
ENV{ key}              环境变量，可以表示任意
PROGRAM              可执行的外部程序，如果程序返回0值，该键则认为为真(true)
RESULT                     上一个PROGRAM调用返回的标准输出。
NAME                     根据这个规则创建的设备文件的文件名。注意：仅仅第一行的NAME描述是有效的，后面的均忽略。 如果你想使用使用两个以上的名字来访问一个设备的话，可以考虑SYMLINK键。
SYMLINK              根据规则创建的字符连接名
OWNER                     设备文件的属组
GROUP                     设备文件所在的组。
MODE                     设备文件的权限，采用8进制
RUN                     为设备而执行的程序列表
LABEL                     在配置文件里为内部控制而采用的名字标签(下下面的GOTO服务)
GOTO                     跳到匹配的规则（通过LABEL来标识），有点类似程序语言中的GOTO
IMPORT{ type}           导入一个文件或者一个程序执行后而生成的规则集到当前文件
WAIT_FOR_SYSFS         等待一个特定的设备文件的创建。主要是用作时序和依赖问题。
PTIONS                     特定的选项： last_rule 对这类设备终端规则执行； ignore_device 忽略当前规则； ignore_remove 忽略接下来的并移走请求。all_partitions 为所有的磁盘分区创建设备文件

我们给出一个列子来解释如何使用这些键。下面的例子来自Fedora Core 5系统的标准配置文件。

KERNEL=="*", OWNER="root" GROUP="root", MODE="0600"
KERNEL=="tty", NAME="%k", GROUP="tty", MODE="0666", OPTIONS="last_rule"
KERNEL=="scd[0-9]*", SYMLINK+="cdrom cdrom-%k"
KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1",
               SYSFS{device/media}=="cdrom", SYMLINK+="cdrom cdrom-%k"
ACTION=="add", SUBSYSTEM=="scsi_device", RUN+="/sbin/modprobe sg"

上面的例子给出了5个规则，每一个都是KERNEL或者ACTION键开头：

*第一个规则是缺省的，他匹配任意被内核识别到的设备，然后设定这些设备的属组是root，组是root，访问权限模式是0600(-rw——-)。这也是一个安全的缺省设置保证所有的设备在默认情况下只有root可以读写

*第二个规则也是比较典型的规则了。它匹配终端设备(tty)，然后设置新的权限为0600，所在的组是tty。它也设置了一个特别的设备文件名:%K。在这里例子里，%k代表设备的内核名字。那也就意味着内核识别出这些设备是什么名字，就创建什么样的设备文件名。

第三行开始的KERNEL==”scd[0-9]”,表示 SCSI CD-ROM 驱动. 它创建一对设备符号连接：cdrom和cdrom-%k。

*第四行，开始的 KERNEL==”hd[a-z]“, 表示ATA CDROM驱动器。这个规则创建和上面的规则相同的符号连接。ATA CDROM驱动器需要sysfs值以来区别别的ATA设备，因为SCSI CDROM可以被内核唯一识别。.

*第五行以 ACTION==”add”开始，它告诉udev增加 /sbin/modprobe sg 到命令列表，当任意SCSI设备增加到系统后，这些命令将执行。其效果就是计算机应该会增加sg内核模块来侦测新的SCSI设备。

当然，上面仅仅是一小部分例子，如果你的系统采用了udev方式，那你应该可以看到更多的规则。如果你想修改设备的权限或者创建信的符号连接，那么你需要熟读这些规则，特别是要仔细注意你修改的那些与之相关的设备。

修改你的udev配置

在修改udev配置之前，我们一定要仔细，通常的考虑是：你最好不要修改系统预置的那些规则，特别不要指定影响非常广泛的配置，比如上面例子中的第一行。不正确的配置可能会导致严重的系统问题或者系统根本就无法这个正确的访问设备。

而我们正确的做法应该是在/etc/udev/rules.d/下创建一个信的规则文件。确定你给出的文件的后缀是rules文件名给出的数字序列应该比 标准配置文件高。比如，你可以创建一个名为99-my-udev.rules的规则文件。在你的规则文件中，你可以指定任何你想修改的配置，比如，假设你 修改修改floppy设备的所在组，还准备创建一个信的符号连接/dev/floppy，那你可以这么写：

KERNEL==”fd[0-9]*“, GROUP=“users“,   SYMLINK+=“floppy“

或者比如我要让让ubuntu串口和USB设备不用root权限访问
在/etc/udev/rules.d/目录下新建一个文件，取名可以是90-tofu.rules， 内容如下：

SUBSYSTEM=="usb", ATTRS{idProduct}=="f408", ATTRS{idVendor}=="040e", GROUP="tofu", MODE="0666"

然后重新插拔设备，即可

某些规则的修改可能需要更深的挖掘。比如，你可能想在一个设备上使用sysfs信息来唯一标识一个设备。这些信息最好通过udevinfo命令来获取
第一种情况是，当你把设备插入系统后，系统为设备产生了设备名（如/dev/sda）。那样的
话，你先用udevinfo -q path -n/dev/sda，命令会产生一个该设备名对应的在sysfs下的路径，如/block/sda。然后，你再用udevinfo -a -p/sys/block/sda，这个命令会显示一堆信息，信息分成很多块。这些信息实际来自于操作系统维护的sysfs链表，不同的块对应不同的路径。你就可以用这些信息来作为udev规则文件中的匹配项。但需要注意的是，同一个规则只能使用同一块中显示的信息，不能跨块书写规则。

第二种情况是，不知道系统产生的设备名，那就只有到/sys目录下去逐个目录查找了，反复用udevinfo　-a -p/sys/path…这个命令看信息，如果对应的信息是这个设备的，那就恭喜你。否则就再换个目录。当然，在这种情况下，成功的可能性比较小。

[root@localhost rules.d]# udevinfo -a -p $(udevinfo -q path        -n      /dev/hda1)
Udevinfo 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 '/block/hda/hda1':    
KERNEL=="hda1"     SUBSYSTEM=="block"     DRIVER==""       
ATTR{stat}=="        1133         2268            2            4"         ATTR{size}=="208782"
ATTR{start}=="63"         ATTR{dev}=="3:1"        looking at parent device '/block/hda':  

KERNELS=="hda"     SUBSYSTEMS=="block"     DRIVERS==""       
ATTRS{stat}=="28905 18814 1234781 302540 34087 133247 849708 981336 0 218340 1283968"
ATTRS{size}=="117210240"         ATTRS{removable}=="0"       
ATTRS{range}=="64"         ATTRS{dev}=="3:0"

looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0/0.0':    

KERNELS=="0.0"     SUBSYSTEMS=="ide"     DRIVERS=="ide-disk"       
ATTRS{modalias}=="ide:m-disk"         ATTRS{drivename}=="hda"      
ATTRS{media}=="disk"      
looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0':    

KERNELS=="ide0"     SUBSYSTEMS==""     DRIVERS==""      
looking at parent device '/devices/pci0000:00/0000:00:1f.1':    
KERNELS=="0000:00:1f.1"     SUBSYSTEMS=="pci"     DRIVERS=="PIIX_IDE"       
ATTRS{broken_parity_status}=="0"         ATTRS{enable}=="1"       
ATTRS{modalias}=="pci:v00008086d000024CAsv0000144Dsd0000C009bc01sc01i8a"
ATTRS{local_cpus}=="1"         ATTRS{irq}=="11"         ATTRS{class}=="0x01018a"
ATTRS{subsystem_device}=="0xc009"         ATTRS{subsystem_vendor}=="0x144d"
ATTRS{device}=="0x24ca"         ATTRS{vendor}=="0x8086"      
looking at parent device '/devices/pci0000:00':    

KERNELS=="pci0000:00"     SUBSYSTEMS==""     DRIVERS=="" 

利用udev可以解决一些问题 比如
可以利用 udev 在一个 USB 设备被加载的时候自动加载上这个设备?
所有的主流发布版 (distro)都包含了 HAL (http://freedesktop.org/wiki/Software_2fhal) 用于这个工作，它也是专门用于监视设备变更的，并且集成进入了桌面软件。

换个角度说，这可以简单的通过 fstab 来实现:/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0
这样，用户可以用如下命令来访问设备:
$mount /media/PENDRIVE

接着我们来讲mdev
mdev是udev的简化版本,是busybox中所带的程序,最适合用在嵌入式系统,而udev一般用在PC上的linux中,相对mdev来说要复杂些,devfs是2.4内核引入的,而在2.6内核中却被udev所替代,
他们有着共同的优点,只是devfs中存在一些未修复的BUG,作者也停止了对他的维护,最显著的一个区别,采用devfs时,当一个并不存在的设备结点时,他却还能自动的加载对应的设备驱动,
而udev则不能,udev认为当加载了不存在的对应的设备驱动的时候不应加载对应的驱动模块，因为加载也没有,浪费了资源.
从本质上来说，udev与mdev他们都是一个应用程序，配置了就可以使用,为了方便使用,我们可以使用busybox自带的mdev,当然也可以去下载udev的源码去编译和移植.

这应该是对udev和mdev的一个理解,我们下次可以再深入一些.

dev 和mdev 是两个使用uevent 机制处理热插拔问题的用户空间程序，两者的实现机理不同。udev 是基于netlink 机制的，它在系统启动时运行了一个deamon 程序udevd
，通过监听内核发送的uevent 来执行相应的热拔插动作，包括创建/删除设备节点，加载/卸载驱动模块等等。mdev 是基于uevent_helper 机制的，它在系统启动时修改了内核中的uevnet_helper 变量
（通过写/proc/sys/kernel/hotplug），值为“/sbin/mdev”。这样内核产生uevent 时会调用uevent_helper 所指的用户级程序，也就是mdev，来执行相应的热拔插动作
。udev 使用的netlink 机制在有大量uevent 的场合效率高，适合用在PC 机上；而mdev 使用的uevent_helper 机制实现简单，适合用在嵌入式系统中。
另外要说明的一点是,uevent_helper 的初始值在内核编译时时可配置的，默认值为/sbin/hotplug。如果想修改它的值，写/proc/sys/kernel/hotplug 文件就可以了，例如：
echo “/sbin/mdev” > /proc/sys/kernel/hotplug

对于热拔插事件 就是hotplug
我们可以分析下热拔插事件 首先呢我们在驱动程序中创建设备节点的时候，流程都是”先创建一个类” 然后在”在类下创建设备”
比如创建一个/dev/xxx 代码如下

static struct class *class;
static struct class_device  *class_dev;
class = class_create(THIS_MODULE, "firstdrv");
class_dev = class_device_create(class , NULL, MKDEV(major, 0), NULL, "xxx");

继续分析源码

class_device_create
    class_device_register
        class_device_add
            kobject_uevent(&class_dev->kobj, KOBJ_ADD);
                kobject_uevent_env
                    /*action_string = "add"*/
                    action_to_string(KOBJ_ADD);  /*add*/
                    /* environment values */
                    /* 分配保存环境变量的内存 */
                    buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);

                    /*设置环境变量*/
                    scratch = buffer;
                    envp [i++] = scratch;
                    scratch += sprintf(scratch, "ACTION=%s", action_string) + 1;
                    envp [i++] = scratch;
                    scratch += sprintf (scratch, "DEVPATH=%s", devpath) + 1;
                    envp [i++] = scratch;
                    scratch += sprintf(scratch, "SUBSYSTEM=%s", subsystem) + 1;

                    call_usermodehelper (argv[0], argv, envp, 0);
                    /*调用用户模式下的辅助程序*/

再分析Busybox的mdev.c

mdev_main
        //temp = /sys/class/xxx_drv/xxx
        ction = getenv("ACTION");
        env_path = getenv("DEVPATH")
        make_device(temp, 0);
            fd = open("/etc/mdev.conf", O_RDONLY);/*根据这个配置文件*/
            /*如果没有这个配置文件的话  就会创建设备节点*/
            /* 确定设备文件名,类型,主次设备号 */
            /device_name = bb_basename(path);  = "xxx"/*


            'c' == > 字符设备节点
            根据"/sys/class/xxx_drv/xxx/dev"的内容确定主次设备号

            mknod(device_name, mode | type, makedev(major, minor)

其实热拔插事件就是利用设备的加入(add)或者移除(remove)，然后把设备的详细信息输出到sys/下 调用/sbin/mdev根据这些环境变量创建设备节点 。

其实原理是跟udev没什么差别，udev也是利用设备加入或者移除时内核所发送的热拔插事件(hotplug event)来工作。在热拔插时，设备的详细信息会由内核输出到位于/sys的sysfs文件系统。udev的设备命名策略、权限控制和事件处理都是在用户态下完成的，它利用sysfs中的信息创建设备节点等工作。

那么也可以利用热拔插事件做一些事情，比如：
我想在linux上接上u盘后自动挂载，就可以写mdev.conf

sda[1-9]+ 0:0 777 * /bin/add_remove_udisk.sh

然后在add_remove_udisk.sh脚本里写入

#!/bin/sh
if [ $ACTION = "add" ]; 
then 
    mount /dev/$MDEV /mnt; 
else 
    umount /mnt; 
fi