Linux设备驱动模型中的热插拔机制.docVIP

热插拔(hotplug，打这个词的时候我常常想到热干面)不一定非要指类似U盘那样的插入拔出，此处的热插拔广义上讲，是指一个设备加入系统，内核如何通知用户空间。举个简单的例子，如果你的电脑中有块PCI网卡，针对该网卡的驱动程序以内核模块的形式被编译(obj-m)，那么Linux系统在启动过程中是如何自动加载该网卡的驱动模块呢？大家都知道现在udev负责干这事，其实除了udev，还可以有其他的手法，你自己就可以这样做。 我们先讨论udev，udev最关键的东西是当系统发现一个设备时，它要能够被通知该事件，一旦它知道了这件事，那么余下的事情就都好说了，无非是个如何查找模块并加载的过程。所以我们看到，这里的关键是热插拔事件的通知机制。Linux的设备模型为此提供了非常完美的支持，其原理其实发源于kset这一层，对此在《深入Linux设备驱动程序内核机制》一书中有详细的描述，虽然这部分看起来蛮复杂，貌似挺能吓唬住一些新手，其实说白了，要点就是通过sysfs建立关系，沟通内核与用户空间，然后就是uevent，也就是下面要说的热插拔事件。 当然设备驱动程序一般不会和这些太底层的kobject/kset家伙打交道，因为更高层次的device,bus和driver把kobject/kset那一层的细节实现都给封装了起来。所以设备热插拔的uevent事件最终的源头来自于device_add，本帖这里肯定不会讨论device与driver如何绑定那一摊子事情。下面看看device_add的源码，是如何实现uevent机制的： drivers/base/core.c int device_add(struct device *dev) { ... kobject_uevent(dev-kobj, KOBJ_ADD); ... } 复制代码 热插拔的核心实现就那一个函数调用，这里device_add对应的是KOBJ_ADD，那么移除设备自然对应KOBJ_REMOVE了。kobject_uevent函数最终调用的是kobject_uevent_env，后者才是真正干事的伙计。 下面给出kobject_uevent_env函数的核心框架： int kobject_uevent_env(struct kobject *kobj, enum kobject_action action, char *envp_ext[]) { ... #if defined(CONFIG_NET) /* send netlink message */ ... #endif /* call uevent_helper, usually only enabled during early boot */ if (uevent_helper[0] !kobj_usermode_filter(kobj)) { char *argv [3]; argv [0] = uevent_helper; argv [1] = (char *)subsystem; argv [2] = NULL; retval = add_uevent_var(env, HOME=/); if (retval) goto exit; retval = add_uevent_var(env, PATH=/sbin:/bin:/usr/sbin:/usr/bin); if (retval) goto exit; retval = call_usermodehelper(argv[0], argv, env-envp, UMH_WAIT_EXEC); }