热插拔的工作原理 hotplug机制和udev

设备节点的创建，是通过sysfs接口分析dev文档取得设备节点号，这个很显而易见。那么udevd是通过什么机制来得知内核里模块的变化情况，如何得知设备的插入移除情况呢？当然是通过hotplug机制了，那 hotplug又是怎么实现的？或说内核是如何通知用户空间一个事件的发生的呢？
答案是通过netlink socket通讯，在内核和用户空间之间传递信息。
内核调用kobject_uevent函数发送netlink message给用户空间，这部分工作通常无需驱动去自己处理，在统一设备模型里面，在子系统这一层面，已将这部分代码处理好了，包括在设备对应的特定的 Kobject创建和移除的时候都会发送相应add和remove消息，当然前提是您在内核中配置了hotplug的支持。
Netlink socket作为一种内核和用户空间的通信方式，不但仅用在hotplug机制中，同样还应用在其他很多真正和网络相关的内核子系统中。
Udevd通过标准的socket机制，创建socket连接来获取内核广播的uevent事件 并解析这些uevent事件

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来完成。
      udevd创建每一个节点的时候，都会fork出一个新的进程来单独完成这个节点的创建工作。
      Uevent_seqnum 用来标识当前的uevent事件的序号（已产生了多少uevent事件），您能够通过如下操作来查看：
$ cat /sys/kernel/uevent_seqnum
2673

      udev的工作原理 当系统内核发现安装或者卸载了某一个硬件设备时，内核会执行hotplug，以便让hotplug去安装或卸载该硬件的驱动程序；hotplug在处理完硬件的驱动程序后，就会去呼叫执行udevd，以便让udevd可以产生或者删除硬件的设备文件。 接着udevd会通过libsysfs读取sys文件系统，以便取得该硬件设备的信息；然后再向namedev查询该外部设备的设备文件信息，例如文件的名称、权限等。最后，udevd就依据上述的结果，在/dev/目录中自动建立该外部设备的设备文件，同时在/etc/udev/rules.d下检查有无针对该设备的使用权限