call_usermodehelper()用来让内核空间的驱动程序启用用户空间的若干应用程序,
如:/sbin/hotplug、/bin/gliethttp_hello等,它的函数原型如下:
static inline int call_usermodehelper(char *path, char **argv, char **envp, enum umh_wait wait);
path --- 用户空间所要启用的应用程序路径,如:"/sbin/hotplug",那么hotplug应用程序就会被内核加载启用
argv --- 传递给启用了的用户空间应用程序的参数argv
envp --- 传递给启用了的用户空间应用程序的环境变量envp,类似int main(int argc, char *_argv[])模式
wait --- 调用call_usermodehelper的内核程序是否等到被exec的用户空间应用程序,如:"/sbin/hotplug"退出后,才继续执行.
call_usermodehelper()执行之后会在工作队列khelper_wq中加入一个工作线程__call_usermodehelper,这个工作队列上的线程运行之后,会根据wait的类型,调用kernel_thread启用相应类型的线程wait_for_helper()或者____call_usermodehelper(),之所以调用kernel_thread生成新的线程,目的在于让并行运行实现最大化,充分利用cpu.
部分代码如下:
if (wait == UMH_WAIT_PROC || wait == UMH_NO_WAIT)
pid = kernel_thread(wait_for_helper, sub_info,
CLONE_FS | CLONE_FILES | SIGCHLD);
else
pid = kernel_thread(____call_usermodehelper, sub_info,
CLONE_VFORK | SIGCHLD);
线程wait_for_helper()或者____call_usermodehelper()最终调用kernel_execve()启动用户空间的应用程序,并把参数传给该应用程序,如:"/sbin/hotplug",由此可知call_usermodehelper()是内核驱动程序向外界应用程序程序传递内核信息的好手段,但是因为内核驱动会产生相当多的hotplug事件,所以后来就使用"/sbin/udevsend"临时代替,到了2.6.15内核之后,高效的netlink广播接口开始被采用,逐渐取代"/sbin/hotplug"和"/sbin/udevsend"的部分角色,成为一个新亮点,悄悄地登上了历史舞台(注:以上是在分析解读usb驱动模型kobject、kset等时的副产品,由于其自身存在着若干复杂性因素,详细深入分析还有待时间做进一步消化--gliethttp)
阅读(2642) | 评论(1) | 转发(0) |