嵌入式Linux——uevent机制：uevent原理分析【转】

转自：https://blog.csdn.net/W1107101310/article/details/80211885

简介：

    本文主要介绍uevent机制是什么，并通过代码分析使用uevent机制生成设备节点的过程。而本文将分为两部分，第一部分我们介绍一些预备知识和uevent的原理，而第二部分——通过代码介绍使用uevent机制创建设备节点。

 Linux内核：linux-2.6.22.6

 所用开发板：JZ2440 V3（S3C2440A）

声明：

    本文主要是看完韦东山老师视频并结合一些博客内容所写，因此文中可能会有其他文章中的内容，如果你觉得我的文章对你构成了侵犯，您可以告诉我，我会对文章进行改正，同时如果文中可能有不正确的地方，敬请指正。谢谢。

第一部分：预备知识和uevent的原理

    下面我们开始讲解预备知识。在讲解之前，我们先来看一个介绍uevent机制的框架图：

 

            该图片来自：Linux设备模型(3)_Uevent

    我们很多人可能不清楚：uevent机制是什么，uevent机制到底做了什么工作？他的那些方面是值得我们研究的？

    我们在刚学习驱动程序的时候并没有使用uevent机制，也就是说我们在程序中没有用到class_create和class_device_create函数，来自动的在用户空间为设备驱动创建设备节点。那时候我们要手动的在用户空间使用mknod命令来创建设备节点。而当我们使用class_create和class_device_create函数后，他们会为我们在用户空间创建设备节点而不用我们再手动的去完成这项工作。而这就是我们对于uevent机制的宏观认识。而我们知道我们的设备节点是为设备驱动所创建的，而设备device和驱动driver都是以链表的形式连接在总线bus上的，而设备——驱动——总线的更上一层就是sysfs层。因此这就引出了我们就要介绍一个组合了：sysfs+mdev。而这对组合将为我们解释uevent机制的原理。我们先来了解sysfs。

    sysfs是一个基于内存的虚拟文件系统，有kernel提供，挂载到/sys 目录下(用mount查看得到 sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime))，负责以设备树的形式向user namespace提供直观的设备和驱动信息。同时sysfs以不同的视角为我们展示当前系统接入的设备：

• /sys/block 历史遗留问题，存放块设备，提供以设备名(如sda)到/sys/devices的符号链接
• /sys/bus 按总线类型分类，在某个总线目录之下可以找到连接该总线的设备的符号链接，指向/sys/devices。某个总线目录之下的 drivers 目录包含了该总线所需的所有驱动的符号链接对应kernel中的 struct bus_type
• /sys/class 按设备功能分类，如输入设备在 /sys/class/input 之下，图形设备在 /sys/class/graphics 之下，是指向 /sys/devices 目录下对应设备的符号链接对应kernel中的 struct class
• /sys/dev 按设备驱动程序分层(字符设备/块设备)，提供以major:minor为名到 /sys/devices 的符号链接对应kernel中的 struct device_driver
• /sys/devices 包含所有被发现的注册在各种总线上的各种物理设备。所有的物理设备都按其在总线上的拓扑结构来显示，除了 platform devices 和 system devices 。platform devices一般是挂在芯片内部高速或者低速总线上的各种控制器和外设，能被CPU直接寻址。system devices不是外设，他是芯片内部的核心结构，比如CPU，timer等，他们一般没有相关的driver，但是会有一些体系结构相关的代码来配置他们对应kernel中的 struct device

    上面展现了在sys目录下总线，设备，驱动和类所对应的文件，而他们的关系为：

• device用于描述各种设备，其保存了所有的设备信息
• driver 用于驱动 device ，其保存了所有能够被它所驱动的设备链表。
• bus 是连接 CPU 和 device 的桥梁，其保存了所有挂载在它上面的设备链表和驱动这些设备的驱动链表。
• class 用于描述一类 device ，其保存了所有该类 device 的设备链表。

    下面我们介绍总线，设备，驱动和类更下一层的结构体。sysfs的功能基于Linux的统一设备模型，他有以下结构体构成：kobject，kset，ktype。同时我们从上面框图中可以看出uevent是在kobject结构体的基础上实现的。

    kobject：统一设备模型中最基本的对象。

1.   struct kobject {
2.   const char *name; //name，该Kobject的名称，同时也是sysfs中的目录名称。
3.   //由于Kobject添加到Kernel时，需要根据名字注册到sysfs中，之后就不能再直接修改该字段。
4.   //如果需要修改Kobject的名字，需要调用kobject_rename接口，该接口会主动处理sysfs的相关事宜。
5.   struct list_head entry; //entry，用于将Kobject加入到Kset中的list_head。
6.   struct kobject *parent; //parent，指向parent kobject，以此形成层次结构（在sysfs就表现为目录结构）。
7.   struct kset *kset; //kset，该kobject属于的Kset。可以为NULL。
8.   //如果存在，且没有指定parent，则会把Kset作为parent
9.   //（别忘了Kset是一个特殊的Kobject）。
10.   struct kobj_type *ktype; //ktype，该Kobject属于的kobj_type。每个Kobject必须有一个ktype，或者Kernel会提示错误。
11.   struct sysfs_dirent *sd; //sd，该Kobject在sysfs中的表示。
12.    
13.   struct kref kref; //kref，"struct kref”类型（在include/linux/kref.h中定义）的变量，为一个可用于原子操作的引用计数。
14.   unsigned int state_initialized:1; //state_initialized，指示该Kobject是否已经初始化，
15.   //以在Kobject的Init，Put，Add等操作时进行异常校验。
16.   unsigned int state_in_sysfs:1; //state_in_sysfs，指示该Kobject是否已在sysfs中呈现，以便在自动注销时从sysfs中移除。
17.   unsigned int state_add_uevent_sent:1; // state_add_uevent_sent/state_remove_uevent_sent，记录是否已经向用户空间发送ADD uevent，
18.   //如果有，且没有发送remove uevent，则在自动注销时，补发REMOVE uevent，
19.   //以便让用户空间正确处理。
20.   unsigned int state_remove_uevent_sent:1;
21.   unsigned int uevent_suppress:1; //uevent_suppress，如果该字段为1，则表示忽略所有上报的uevent事件。
22.   };

    注：Uevent提供了“用户空间通知”的功能实现，通过该功能，当内核中有Kobject的增加、删除、修改等动作时，会通知用户空间。

    Ktype：代表Kobject（严格地讲，是包含了Kobject的数据结构）的属性操作集合（由于通用性，多个Kobject可能共用同一个属性操作集，因此把Ktype独立出来了）。

1.   struct kobj_type {
2.   void (*release)(struct kobject *kobj); //release，通过该回调函数，可以将包含该种类型kobject的数据结构的内存空间释放掉。
3.   const struct sysfs_ops *sysfs_ops; //sysfs_ops，该种类型的Kobject的sysfs文件系统接口。
4.   struct attribute **default_attrs; //default_attrs，该种类型的Kobject的atrribute列表
5.   //（所谓attribute，就是sysfs文件系统中的一个文件）。
6.   //将会在Kobject添加到内核时，一并注册到sysfs中。
7.   const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
8.   //child_ns_type/namespace，和文件系统（sysfs）的命名空间有关
9.   const void *(*namespace)(struct kobject *kobj);
10.   };

    实际上这里实现的类似于对 kobject 的派生，包含不同 kobj_type 的kobject 可以看做不同的子类。通过实现相同的函数来实现多态。在这样的设计下，每一个内嵌Kobject的数据结构(如kset、device、device_driver等)，都要实现自己的 kobj_type ，并定义其中的回调函数。

    Kset:一个特殊的Kobject（因此它也会在"/sys/“文件系统中以目录的形式出现），它用来集合相似的Kobject（这些Kobject可以是相同属性的，也可以不同属性的）。

1.   struct kset {
2.   struct list_head list; //list用于保存该kset下所有的kobject的链表。
3.   spinlock_t list_lock; //list自旋锁
4.   struct kobject kobj; //kobj，该kset自己的kobject（kset是一个特殊的kobject，也会在sysfs中以目录的形式体现）。
5.   const struct kset_uevent_ops *uevent_ops; //uevent_ops，该kset的uevent操作函数集。
6.   //当任何Kobject需要上报uevent时，都要调用它所从属的kset的uevent_ops，添加环境变量，
7.   //或者过滤event（kset可以决定哪些event可以上报）。
8.   //因此，如果一个kobject不属于任何kset时，是不允许发送uevent的。
9.   };

    而kset的uevent操作回调函数为：

1.   struct kset_uevent_ops {
2.   int (* const filter)(struct kset *kset, struct kobject *kobj);
3.   //filter，当任何Kobject需要上报uevent时，它所属的kset可以通过该接口过滤，
4.   //阻止不希望上报的event，从而达到从整体上管理的目的。
5.   const char *(* const name)(struct kset *kset, struct kobject *kobj);
6.   //name，该接口可以返回kset的名称。如果一个kset没有合法的名称，
7.   //则其下的所有Kobject将不允许上报uvent
8.   int (* const uevent)(struct kset *kset, struct kobject *kobj,
9.   struct kobj_uevent_env *env);
10.   //uevent，当任何Kobject需要上报uevent时，它所属的kset可以通过该接口统一为这些event添加环境变量。
11.   //因为很多时候上报uevent时的环境变量都是相同的，因此可以由kset统一处理，就不需要让每个Kobject独自添加了。
12.   };

    注意Kset和 ktype 的关联，kobject 会利用成员 kset 找到自已所属的kset，然后才设置自身的 ktype 为 kobj.ktype 。当没有指定 kset 成员时，才会用 ktype 来建立关系。

     由于 kobject 调用的是它所属 kset 的uevent操作函数，所以 kset 可以对其行为进行控制。如果kobject不属于任何 kset ，则无法发送uevent。

 

总结，Ktype以及整个Kobject机制的理解。

    Kobject的核心功能是：保持一个引用计数，当该计数减为0时，自动释放（由本文所讲的kobject模块负责） Kobject所占用的meomry空间。这就决定了Kobject必须是动态分配的（只有这样才能动态释放）。 
    而Kobject大多数的使用场景，是内嵌在大型的数据结构中（如Kset、device_driver等），因此这些大型的数据结构，也必须是动态分配、动态释放的。那么释放的时机是什么呢？是内嵌的Kobject释放时。但是Kobject的释放是由Kobject模块自动完成的（在引用计数为0时），那么怎么一并释放包含自己的大型数据结构呢？ 
    这时Ktype就派上用场了。我们知道，Ktype中的release回调函数负责释放Kobject（甚至是包含Kobject的数据结构）的内存空间，那么Ktype及其内部函数，是由谁实现呢？是由上层数据结构所在的模块！因为只有它，才清楚Kobject嵌在哪个数据结构中，并通过Kobject指针以及自身的数据结构类型，找到需要释放的上层数据结构的指针，然后释放它。 
    讲到这里，就清晰多了。所以，每一个内嵌Kobject的数据结构，例如kset、device、device_driver等等，都要实现一个Ktype，并定义其中的回调函数。同理，sysfs相关的操作也一样，必须经过ktype的中转，因为sysfs看到的是Kobject，而真正的文件操作的主体，是内嵌Kobject的上层数据结构！ 
    顺便提一下，Kobject是面向对象的思想在Linux kernel中的极致体现，但C语言的优势却不在这里，所以Linux kernel需要用比较巧妙（也很啰嗦）的手段去实现。

 

mdev原理

    上面我们分析了sysfs，下面我们就开始分析mdev，我们通过分析mdev了解他与sysfs的关系。mdev在busybox的代码包中能找到，位于busybox/util-linux/mdev.c文件中，他通过uevent_helper函数被调用。在mdev中主要完成两件事情：

第一件事：

    执行mdev -s命令时，mdev扫描/sys/block(块设备保存在/sys/block目录下,内核2.6.25版本以后，块设备也保存在/sys /class/block目录下。mdev扫描/sys/block是为了实现向后兼容)和/sys/class两个目录下的dev属性文件，从该dev 属性文件中获取到设备编号(dev属性文件以”major:minor\n”形式保存设备编号)，并以包含该dev属性文件的目录名称作为设备名 device_name(即包含dev属性文件的目录称为device_name，而/sys/class和device_name之间的那部分目录称为 subsystem。也就是每个dev属性文件所在的路径都可表示为/sys/class/subsystem/device_name/dev)，在 /dev目录下创建相应的设备文件。例如，cat /sys/class/tty/tty0/dev会得到4:0，subsystem为tty,device_name为tty0。

第二件事：

    当mdev因uevnet事件(以前叫hotplug事件)被调用时，mdev通过由uevent事件传递给它的环境变量获取到：引起该uevent 事件的设备action及该设备所在的路径device path。然后判断引起该uevent事件的action是什么。并根据action的不同做相应操作。若该action是add，即有新设备加入到系统中，不管该设备是虚拟设备还是实际物理设备，mdev都会通过device path路径下的dev属性文件获取到设备编号，然后以device path路径最后一个目录(即包含该dev属性文件的目录)作为设备名，在/dev目录下创建相应的设备文件。若该action是remote，即设备已 从系统中移除，则删除/dev目录下以device path路径最后一个目录名称作为文件名的设备文件。如果该action既不是add也不是remove，mdev则什么都不做。

    由上面可知，如果我们想在设备加入到系统中或从系统中移除时，由mdev自动地创建和删除设备文件，那么就必须做到以下三点：

1. 在/sys/class 的某一subsystem目录下，

2. 创建一个以设备名device_name作为名称的目录，

3. 并且在该device_name目录下还必须包含一个 dev属性文件，该dev属性文件以”major:minor\n”形式输出设备编号。

    而从上面这些内容我们可以知道，sysfs为uevent机制做前期的准备工作，即创建相应的目录，而mdev则是在sysfs的基础上通过调用sysfs创建的目录或文件来实现设备节点的创建。

第二部分：结合代码介绍使用uevent机制创建设备节点

    现在我们就要结合代码分析uevent机制了，而要分析这个机制我们就要从class_create和class_device_create这两个函数来分析这个过程是怎么实现的。我们现在先分析class_create：

    下面是class_create函数的层级关系：

1.   class_create(THIS_MODULE,"buttonsdrv");
2.       class_register(cls);
3.           kobject_set_name(&cls->subsys.kobj, "%s", cls->name); //将类的名字led_class赋值给对应的kset
4.   subsys_set_kset(cls, class_subsys);
5.   subsystem_register(&cls->subsys);
6.       kset_register(s); //创建class设备类目录
7.   kset_add(k);
8.               kobject_add(&k->kobj);
9.   kobject_shadow_add(kobj, NULL);
10.               parent = kobject_get(kobj->parent); // parent即class_kset.kobj,即/sysfs/class对应的目录
11.       list_add_tail(&kobj->entry,&kobj->kset->list);
12.       create_dir(kobj, shadow_parent); //创建一个class设备类目录
13.   sysfs_create_dir(kobj, shadow_parent); //该接口是sysfs文件系统接口，代表创建一个目录，不再展开。

    从上面我们可以看出kobject在sysfs中对应的是目录（dir），当我们注册一个kobject时，会调用kobject_add(&k->kobj);然后在其后创建class设备目录。而同时我们可以看出class_create函数是为class_device_create函数做了目录的准工作。

    而从文章开始介绍的图片我们知道当kobject的状态发生改变(如,add, remove等)时，会通知用户空间，用户空间接收到事件通知后可以做相应的处理。
    而uevent把事件上报给用户空间有两种途径：
　　1.通过kmod模块，直接调用用户空间的可执行程序或脚本。
　　2.通过netlink通信机制，将事件从内核空间传递到用户空间。

    而本文主要讲解通过kmod模块，直接调用用户空间的可执行程序或脚本。而通过kobject.h，uevent模块提供了如下的API（这些API的实现是在"lib/kobject_uevent.c”文件中）：

1.   int kobject_uevent(struct kobject *kobj, enum kobject_action action);
2.   int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
3.   char *envp[]);
4.    
5.   int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
6.    
7.   int kobject_action_type(const char *buf, size_t count,enum kobject_action *type);

    下面我们从class_device_create函数开始分析，看他是如何走到kobject_uevent函数的。我们看class_device_create函数的层级关系：

1.   class_device_create(buttonsdrv_class,NULL,MKDEV(auto_major,0),NULL,"buttonsdrv");
2.   class_device_register(class_dev);
3.   class_device_add(class_dev);
4.   class_dev = class_device_get(class_dev);
5.   parent_class = class_get(class_dev->class);
6.   parent_class_dev = class_device_get(class_dev->parent);
7.   kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
8.   kobject_add(&class_dev->kobj);
9.   class_device_create_file(class_dev, attr);
10.   class_device_add_groups(class_dev);
11.   make_deprecated_class_device_links(class_dev);
12.   kobject_uevent(&class_dev->kobj, KOBJ_ADD);

    从前面的代码看class_create和class_device_create做了很多相似的工作——就是创建目录，而当到kobject_uevent函数后，他们就不一样了，下面我们分析kobject_uevent函数

1.   /**
2.   * 通过终端事件通知用户层
3.   *
4.   * @action: 发生的事件 (通常是 KOBJ_ADD 和 KOBJ_REMOVE)
5.   * @kobj: 事件发生的kobject 结构体
6.   *
7.   */
8.   int kobject_uevent(struct kobject *kobj, enum kobject_action action)
9.   {
10.   return kobject_uevent_env(kobj, action, NULL);
11.   }

    他调用了kobject_uevent_env函数，而上面的介绍中我们知道了要发送事件，那么都有什么事件那？

    我们看linux-3.5/include/linux/kobject.h

1.   enum kobject_action {
2.   KOBJ_ADD, //ADD/REMOVE，Kobject（或上层数据结构）的添加/移除事件。
3.   KOBJ_REMOVE,
4.   KOBJ_CHANGE, //CHANGE，Kobject（或上层数据结构）的状态或者内容发生改变。
5.   //CHANGE，如果设备驱动需要上报的事件不再上面事件的范围内，
6.   //或者是自定义的事件，可以使用该event，并携带相应的参数。
7.   KOBJ_MOVE, //MOVE，Kobject（或上层数据结构）更改名称或者更改Parent（意味着在sysfs中更改了目录结构）。
8.   KOBJ_ONLINE, //ONLINE/OFFLINE，Kobject（或上层数据结构）的上线/下线事件，其实是是否使能。
9.   KOBJ_OFFLINE,
10.   KOBJ_MAX
11.   };

    下面我们接着分析kobject_uevent_env函数：

1.   /**
2.   * 发送一个带有环境变量的事件
3.   *
4.   * @action: 发生的事件(通常为KOBJ_MOVE)
5.   * @kobj: 事件发生的kobject结构体
6.   * @envp_ext: 环境变量数据指针
7.   *
8.   */
9.   int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
10.   char *envp_ext[])
11.   {
12.   action_string = action_to_string(action);
13.    
14.   /* 查找当前kobject或其parent是否从属于某个kset;如果都不从属于某个kset，则返回错误。(说明一个kobject若没有加入kset，是不会上报uevent的) */
15.   top_kobj = kobj;
16.   while (!top_kobj->kset && top_kobj->parent) {
17.   top_kobj = top_kobj->parent;
18.   }
19.   if (!top_kobj->kset) {
20.   pr_debug("kobject attempted to send uevent without kset!\n");
21.   return -EINVAL;
22.   }
23.    
24.   kset = top_kobj->kset;
25.   uevent_ops = kset->uevent_ops;
26.    
27.   /* 如果所属的kset有uevent_ops->filter,则调用该函数，若该函数返回0，则过滤此次上报。(kset 可以通过filter接口过滤不希望上报的event) */
28.   if (uevent_ops && uevent_ops->filter)
29.   if (!uevent_ops->filter(kset, kobj)) {
30.   pr_debug("kobject filter function caused the event to drop!\n");
31.   return 0;
32.   }
33.    
34.   /*判断所属的kset是否有合法的名称,若uevent_ops->name存在就用其返回的名称作为subsystem;若uevent_ops->name不存在就用kset本身的kobject的名称作为subsystem;若没有合法的名称，则不上报uevent */
35.   if (uevent_ops && uevent_ops->name)
36.   subsystem = uevent_ops->name(kset, kobj);
37.   else
38.   subsystem = kobject_name(&kset->kobj);
39.   if (!subsystem) {
40.   pr_debug("unset subsytem caused the event to drop!\n");
41.   return 0;
42.   }
43.    
44.   /* 分配一个此次上报的环境变量 */
45.   envp = kzalloc(NUM_ENVP * sizeof (char *), GFP_KERNEL);
46.   if (!envp)
47.   return -ENOMEM;
48.    
49.   /*分配一个此次上报的用于保存环境变量的buffer, */
50.   buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
51.   if (!buffer) {
52.   retval = -ENOMEM;
53.   goto exit;
54.   }
55.    
56.   /* 获得该kobject在sysfs中路径 */
57.   devpath = kobject_get_path(kobj, GFP_KERNEL);
58.   if (!devpath) {
59.   retval = -ENOENT;
60.   goto exit;
61.   }
62.    
63.   /* uevent_helper的环境变量*/
64.   envp[i++] = "HOME=/";
65.   envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
66.    
67.   /* 添加环境变量 */
68.   scratch = buffer;
69.   envp [i++] = scratch;
70.   scratch += sprintf(scratch, "ACTION=%s", action_string) + 1;
71.   envp [i++] = scratch;
72.   scratch += sprintf (scratch, "DEVPATH=%s", devpath) + 1;
73.   envp [i++] = scratch;
74.   scratch += sprintf(scratch, "SUBSYSTEM=%s", subsystem) + 1;
75.   for (j = 0; envp_ext && envp_ext[j]; j++)
76.   envp[i++] = envp_ext[j];
77.   /* just reserve the space, overwrite it after kset call has returned */
78.   envp[i++] = seq_buff = scratch;
79.   scratch += strlen("SEQNUM=18446744073709551616") + 1;
80.    
81.   /* 如果 uevent_ops->uevent 存在，调用该接口，添加kset统一的环境变量到env指针 */
82.   if (uevent_ops && uevent_ops->uevent) {
83.   retval = uevent_ops->uevent(kset, kobj,
84.   &envp[i], NUM_ENVP - i, scratch,
85.   BUFFER_SIZE - (scratch - buffer));
86.   if (retval) {
87.   pr_debug ("%s - uevent() returned %d\n",
88.   __FUNCTION__, retval);
89.   goto exit;
90.   }
91.   }
92.    
93.   /* 调用add_uevent_var接口，添加格式为"SEQNUM=%llu”的序列号 */
94.   spin_lock(&sequence_lock);
95.   seq = ++uevent_seqnum;
96.   spin_unlock(&sequence_lock);
97.   sprintf(seq_buff, "SEQNUM=%llu", (unsigned long long)seq);
98.    
99.    
100.   /* 以uevent_helper、 subsystem 以及添加了标准环境变量（HOME=/，PATH=/sbin:/bin:/usr/sbin:/usr/bin）的env指针为参数,调用kmod模块提供的call_usermodehelper函数，上报uevent。 */
101.   if (uevent_helper[0]) {
102.   char *argv [3];
103.    
104.   argv [0] = uevent_helper;
105.   argv [1] = (char *)subsystem;
106.   argv [2] = NULL;
107.   call_usermodehelper (argv[0], argv, envp, 0);
108.   }
109.   }

    uevent模块通过kmod上报uevent时，会通过call_usermodehelper函数，调用用户空间的可执行文件（或者脚本，简称uevent helper）处理该event。而该uevent helper的路径保存在uevent_helper数组中。可以在编译内核时，通过CONFIG_UEVENT_HELPER_PATH配置项，静态指定uevent helper。
    但这种方式会为每个event fork一个进程，随着内核支持的设备数量的增多，这种方式在系统启动时将会是致命的（可以导致内存溢出等）。因此只有在早期的内核版本中会使用这种方式，现在内核不再推荐使用该方式。因此内核编译时，需要把该配置项留空。在系统启动后，大部分的设备已经ready，可以根据需要，重新指定一个uevent helper，以便检测系统运行过程中的热拔插事件。
    这可以通过把helper的路径写入到"/sys/kernel/uevent_helper"文件中实现。实际上，内核通过sysfs文件系统的形式，将uevent_helper数组开放到用户空间，供用户空间程序修改访问，具体可参考"./kernel/ksysfs.c”中相应的代码。

    在/etc/init.d/rcS脚本中添加 echo "/sbin/mdev" > /proc/sys/kernel/hotplug，会发现cat /sys/kernel/uevent_helper 即是/sbin/mdev。说明/proc/sys/kernel/hotplug中的可执行文件路径最终还是会写到/sys/kernel/uevent_helper中。自己手动echo "/kernel/main" > uevent_helper(之前的/sbin/mdev会被覆盖)，当lsmod、rmmod时，/sys/kernel/uevent_helper中的/kernel/main会执行，表明事件已经上报给用户空间。

下面我们看在Busybox中是如何创建设备节点的。

    轮到mdev出场了，前面的描述都是在sysfs文件系统中创建目录或者文件，而应用程序访问的设备文件则需要创建在/dev/目录下。该项工作由mdev完成。
    mdev的原理是解释/etc/mdev.conf文件定义的命名设备文件的规则，并在该规则下根据环境变量的要求来创建设备文件。mdev.conf由用户层指定，因此更具灵活性。本文无意展开对mdev配置脚本的分析。相关知识可以看我的翻译：mdev.conf翻译

    mdev相应的程序在Busybox/util-linux/mdev.c

1.   int mdev_main(int argc UNUSED_PARAM, char **argv)
2.       xchdir("/dev");
3.       if (argv[1] && strcmp(argv[1], "-s")//系统启动时mdev –s才会执行这个分支
4.       else
5.       action = getenv("ACTION");
6.       env_path = getenv("DEVPATH");
7.       G.subsystem = getenv("SUBSYSTEM");
8.       snprintf(temp, PATH_MAX, "/sys%s", env_path);//到/sysfs/devices/led目录
9.       make_device(temp, /*delete:*/ 0);
10.       strcpy(dev_maj_min, "/dev"); //读出dev属性文件，得到设备号
11.       open_read_close(path, dev_maj_min + 1, 64);    
12.       ….
13.       mknod(node_name, rule->mode | type, makedev(major, minor)) //最终mknod创建节点

    最终我们会跟踪到mknod在/dev/目录下创建了设备文件。

参考文献：

sysfs、udev 和 它们背后的 Linux 统一设备模型
Linux设备模型(2)_Kobject
Linux 设备文件的创建和mdev
内核发送uevent的API，用户空间解析uevent
Linux设备模型(3)_Uevent
设备模型的uevent机制

标签：Linux,uevent,kobject,嵌入式,Kobject,kobj,kset,class
来源： https://www.cnblogs.com/sky-heaven/p/14042108.html