linux udev

                                  Udev 基本工作原理  {z转载}
  udev简介：

    早期的linux的/dev目录下有一大堆设备文件，不管你的主机上是否有这些设备，相当于提供一个标准接口，比
如 /dev/sda 一般表示 SISC 盘第一块磁盘，但你主机上即使没有这种磁盘，/dev/sda还是存在。
   于是，这就有个问题：/dev/下会有很多实际上并不需要的文件，尽管这些文件占用不了多少空间（都是一字
节的大小）
    
后来linux只在/dev上保留一些必要的设备文件，比如 /dev/console (表示控制台)等，其它的由udev在系统启
动时检测并加载，比如 如果扫描到你有 SISC 设备（包括U盘）就在 /dev/下增加一个设备文件，比如 /dev/sda ，
换句话说，有udev的前提下，/dev下的设备文件，就表示你的主机真的有这个设备

1         基本概念
udev文档系统是针对2.6内核，提供一个基于用户空间的动态设备节点管理和命名的解决方案，网上关于为什么要使用udev文档系统，udev文档系统和devfs文档系统的比较，等等的文章已很多了，假如您想了解这方面的内容，请直接搜索相关的关键字。
udev的官方网址：
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
src code的下载地址：

此外，关于udev的rules规则的撰写，网上也有很多文章，假如要获得最准确的版本，能够在src code的代码树里找到writing_udev_rules的帮助文档，这个文档其实没有逐条介绍rules的任何关键字，能够结合man udev 和 udev自带的一些rules文档来理解如何撰写您所需要的规则文档。
2         安装和启动
2.1        安装
Udev的代码树里的版本很多，我下载的最新的版本是udev-117，配合2.6.21版本的内核能够正常使用。网上很多文章介绍的可能都是稍微早期一些的版本，有些步骤包括udev的README文档似乎描述的不是很准确。
基本上这个版本的udev需要注意的是，安装时只需要udevd，udevadm两个文档，其他必需的包括udevtrigger等只是udevadm的一个符号链接。udevstart不是必需的。当然Udev.conf等配置文档还是相同。
2.2        启动
您能够在启动脚本中用udevd –d 参数启动udev文档系统的守护进程，然后使用udevtrigger将buildin的设备驱动的节点创建出来，以后模块插入移除时节点的管理会自动处理。
能够正常加载udev的前提，基本包括如下操作：
       配置路径变量
      加载sysfs文档系统
      加载一个基于ram的可写的/dev目录（其实，只要提供一个可写的目录即可，目录路径本身也是能够配置的）
    /dev目录下需要有已创建好的 console节点和null节点
脚本类似：
# Set the path
PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH
# mount proc and devpts filesystem
/bin/mount -a
mknod /dev/console c 5 1
mknod /dev/null c 1 3
/sbin/udevd -d
/sbin/udevtrigger
Mount使用的fstab文档类似：
none                    /tmp                    ramfs   defaults        0 0
udev                    /dev                    ramfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
当然，您的系统上可能还会需要预先创建一些其他的设备节点，比如串口的ttySx 才能正常启动shell，完成以上脚本的执行，那就要看具体情况了。
3         使用中的一些问题的思考
3.1        关于规则的多次匹配
帮助文档中说一个设备能够被多条规则多次匹配，但是，需要明确的一点是：
多次匹配只能添加多个Symlink，不能创建多个Name：
例如：
KERNEL=="mtdblock4", NAME+="mtdbb4"
KERNEL=="mtdblock4", NAME+="%k"
就只会创建 /dev/mtdbb4 而不会创建/dev/mtdblock4
而类似：
KERNEL=="mtdblock4", NAME+="mtdbb4"
KERNEL=="mtdblock4", SYMLINK+="mtdbb4link"
是能够正常工作的。
3.2        关于udev.conf的语法
可能大家会发现，似乎没有什么周详文档描述udev.conf的写法，实际上从udevd的代码里能够看出：
udev.conf文档里面只会解析这三个参数：
udev_root 定义udev的目录路径
udev_rules 定义udev的规则文档的目录路径
udev_log 定义log的级别
也许以后会添加一些别的配置参数？
4         基本工作原理方面的问题
这部分主要是分析了一下udev的source code，对一些自己关心的问题的理解
4.1        Udevd如何获取内核的这些模块动态变化的信息
设备节点的创建，是通过sysfs接口分析dev文档取得设备节点号，这个很显而易见。那么udevd是通过什么机制来得知内核里模块的变化情况，如何得 知设备的插入移除情况呢？当然是通过hotplug机制了，那hotplug又是怎么实现的？或说内核是如何通知用户空间一个事件的发生的呢？
答案是通过netlink socket通讯，在内核和用户空间之间传递信息。
内核调用kobject_uevent函数发送netlink message给用户空间，这部分工作通常无需驱动去自己处理，在统一设备模型里面，在子系统这一层面，已将这部分代码处理好了，包括在设备对应的特定的 Kobject创建和移除的时候都会发送相应add和remove消息，当然前提是您在内核中配置了hotplug的支持。
Netlink socket作为一种内核和用户空间的通信方式，不但仅用在hotplug机制中，同样还应用在其他很多真正和网络相关的内核子系统中。
Udevd通过标准的socket机制，创建socket连接来获取内核广播的uevent事件 并解析这些uevent事件。
4.2        Udevd如何监控规则文档的变更
假如内核版本足够新的话，在规则文档发生变化的时候，udev也能够自动的重新应用这些规则，这得益于内核的inotify机制， inotify是一种文档系统的变化通知机制，如文档增加、删除等事件能够立即让用户态得知。
在udevd中，对inotify和udev的netlink socket文档描述符都进行了select的等待操作。有事件发生以后再进一步处理。
4.3        Udevtrigger的工作机制？
运行udevd以后，使用udevtrigger的时候，会把内核中已存在的设备的节点创建出来，那么他是怎么做到这一点的？分析udevtrigger的代码能够看出：
udevtrigger通过向/sysfs 文档系统下现有设备的uevent节点写"add"字符串，从而触发uevent事件，使得udevd能够接收到这些事件，并创建buildin的设备驱动的设备节点连同任何已insmod的模块的设备节点。
所以，我们也能够手工用命令行来模拟这一过程：
/ # echo "add" > /sys/block/mtdblock2/uevent
/ #
/ # UEVENT[178.415520] add      /block/mtdblock2 (block)
但是，进一步看代码，您会发现，实际上，不管您往uevent里面写什么，都会触发add事件，这个从kernel内部对uevent属性的实现函数能够看出来，默认的实现是：
static ssize_t store_uevent(struct device *dev, struct device_attribute *attr,
                         const char *buf, size_t count)
{
       kobject_uevent(&dev->kobj, KOBJ_ADD);
       return count;
}
所以不管写的内容是什么，都是触发add操作，真遗憾，我还想通过这个属性实验remove的操作。 不知道这样限制的原因是什么。
而udevstart的实现方式和udevtrigger就不同了，他基本上是重复实现了udevd里面的机制，通过遍历sysfs，自己完成设备节点的创建，不通过udevd来完成。
4.4        其他
      udevd创建每一个节点的时候，都会fork出一个新的进程来单独完成这个节点的创建工作。
      Uevent_seqnum 用来标识当前的uevent事件的序号（已产生了多少uevent事件），您能够通过如下操作来查看：
$ cat /sys/kernel/uevent_seqnum
2673


问答：

问：什么是udev?
答：udev是一种工具，它能够根据系统中的硬件设备的状态动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下。使用udev后，在/dev目录下就只包含系统中真正存在的设备。

问：udev支持什么内核？
答：udev只支持linux-2.6内核，因为udev严重依赖于sysfs文件系统提供的信息，而sysfs文件系统只在linux-2.6内核中才有。

问：udev是一个内核程序还是用户程序？
答：udev是一个用户程序（user-mode daemon）。

问：udev和devfs有什么差别？
答：udev能够实现所有devfs实现的功能。但udev运行在用户模式中，而devfs运行在内核中。据称：devfs具有一些不太容易解决的先天缺陷。

问：udev的配置文件放在哪里？
答：udev是一个用户模式程序。它的配置文件是/etc/udev/udev.conf。这个文件一般缺省有这样几项：


udev_root="/dev" ; udev产生的设备文件的根目录是/dev
udev_db="/dev/.udevdb" ; 通过udev产生的设备文件形成的数据库
udev_rules="/etc/udev/rules.d" ;用于指导udev工作的规则所在目录。
udev_log="err" ;当出现错误时，用syslog记录错误信息。


问：udev的工作过程是怎样的？
答：由于没有研究过udev的源程序，不敢贸然就说udev的工作过程。我只是通过一些网上的资料和udev的说明文档，大致猜测它的工作过程可能是这样的。


当 内核检测到在系统中出现了新设备后，内核会在sysfs文件系统中为该新设备生成一项新的记录，一般sysfs文件系统会被mount到 /sys目录中。新记录是以一个或多个文件或目录的方式来表示。每个文件都包含有特定的信息。（信息是如何表述的，还要另外研究？）
udev在系统中是以守护进程的方式udevd在运行，它通过某种途径（到底什么途径，目前还没搞懂。）检测到新设备的出现，通过查找设备对应的sysfs中的记录得到设备的一些信息。
udev 会根据/etc/udev/udev.conf文件中的udev_rules指定的目录，逐个检查该目录下的文件，这个目录下的文件都是针对某类或某个设 备应该施行什么措施的规则文件。udev读取文件是按照文件名的ASCII字母顺序来读取的，如果udev一旦找到了与新加入的设备匹配的规则，udev 就会根据规则定义的措施对新设备进行配置。同时不再读后续的规则文件。
问：udev的规则文件的语法是怎样的？
答：udev的规则文件 以行为单位，以"#"开头的行代表注释行。其余的每一行代表一个规则。每个规则分成一个或多个“匹配”和“赋值”部分。“匹配”部分用“匹配“专用的关键 字来表示，相应的“赋值”部分用“赋值”专用的关键字来表示。“匹配”关键字包括：ACTION，KERNEL，BUS， SYSFS等等，“赋值”关键字包括：NAME，SYMLINK，OWNER等等。具体详细的描述可以阅读udev的man文档。

下面举个例子来说明一下，有这样一条规则：
SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0d:87:f6:59:f3", IMPORT="/sbin/rename_netiface %k eth0"
这个规则中的“匹配”部分有三项，分别是SUBSYSTEM，ACTION和SYSFS。而"赋值"部分有一项，是IMPORT。这个规则就是说，当系统 中出现的新硬件属于net子系统范畴，系统对该硬件采取的动作是加入这个硬件，且这个硬件在SYSFS文件系统中的“address”信息等于“00： 0d..."时，对这个硬件在udev层次施行的动作是调用外部程序/sbin/rename_netiface，传递的参数有两个，一个是“%k”，代 表内核对该新设备定义的名称。另一个是”eth0“。
从上面这个例子中可以看出，udev的规则的写法比较灵活的，尤其在“匹配”部分中，可以通过诸如”*“, ”?“,[a-c],[1-9]等shell通配符来灵活匹配多个匹配项。具体的语法可以参考udev的man文档。

问：udev怎样做到不管设备连接的顺序而维持一个统一的设备名？
答： 实际上，udev是通过对内核产生的设备名增加别名的方式来达到上述目的的。前面说过，udev是用户模式程序，不会更改内核的行为。因此，内核依然会我 行我素地产生设备名如sda,sdb等。但是，udev可以根据设备的其他信息如总线（bus），生产商（vendor）等不同来区分不同的设备，并产生 设备文件。udev只要为这个设备文件取一个固定的文件名就可以解决这个问题。在后续对设备的操作中，只要引用新的设备名就可以了。但为了保证最大限度的 兼容，一般来说，新设备名总是作为一个对内核自动产生的设备名的符号链接（link）来使用的。

例如：内核产生了sda设备名，而根据信息，这个设备对应于是我的内置硬盘，那我就可以制定udev规则，让udev除了产生/dev/sda设备文件 外，另外创建一个符号链接叫/dev/internalHD。这样，我在fstab文件中，就可以用/dev/internalHD来代替原来的 /dev/sda了。下次，由于某些原因，这个硬盘在内核中变成了sdb设备名了，那也不用着急，udev还会自动产生/dev/internalHD这 个链接，并指向正确的/dev/sdb设备。所有其他的文件像fstab等都不用修改。

问：怎样才能找到这些设备信息，并把他们放到udev的规则文件中来匹配呢？
答：这个问题比较难，网上资料不多，我只找到一篇文章来介绍如何写udev的规则。他的基本方法是通过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...这个命令看信息，如果对应的信息是这个设备的，那就恭喜你。否则就再换个目录。当然，在这种情况下，成功的可能性比较小。