仔细分析了一下AutoYaST的设计，发现它至少还是允许增补驱动程序的，但仅仅支持最简单的用配置文件写死的insmod方式，好吧，只要还给了这个勉强算得上可扩充的途径，我一样能把驱动在线加载模块集成进来。由于只能固定调用某个驱动，所以必须从内核模块下手。把现有程序改造成内核模块显然是不现实的，好在Linux内核中还提供了这样一个调用用户态程序的接口：call_usermodehelper()，你可以在kmod.h中找到它。功能很简单，调用一个用户态程序，并且可以选择是否阻塞直到它执行完成。
顺着这个思路，只要写一个简单的虚桩式内核模块，在其初始化函数中调用我们真正想要执行的用户态程序即可达到目的了。但是，当我提出这个方案后，立即有同事质疑：在内核模块初始化阶段加载别的内核模块，搞不好会锁死内核吧？“搞不好”至少说明他也不肯定，为了找寻答案，我分析了一下内核中系统调用sys_init_module()的代码（以2.6.17为蓝本）。
引用:asmlinkage long
sys_init_module(void __user *umod,
unsigned long len,
const char __user *uargs)
{
......
/* Only one module load at a time, please */
if (mutex_lock_interruptible(&module_mutex) != 0)
return -EINTR;
刚进入就加锁了，似乎有点不妙。紧接着开始加载内核模块：
引用:/* Do all the hard work */
mod = load_module(umod, len, uargs);
if (IS_ERR(mod)) {
mutex_unlock(&module_mutex);
return PTR_ERR(mod);
}
/* Now sew it into the lists. They won't access us, since
strong_try_module_get() will fail. */
stop_machine_run(__link_module, mod, NR_CPUS);
/* Drop lock so they can recurse */
mutex_unlock(&module_mutex);
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_COMING, mod);
/* Start the module */
if (mod->init != NULL)
ret = mod->init();
看来这段代码的作者（或维护者）似乎早就预见到了我所面临的场景。内核模块的加载和初始化被清晰的分为两步，由于加载过程需要链接内核模块，因此必须加锁，而后续的初始化过程已经不会影响内核的完整性了，所以自然可以在解锁后进行。
排除这个疑虑后，我写了一个简单的用于检验上述思路的内核模块：
引用:#include
#include
#include
static int __init kmod_init(void)
{
int ret;
char *envp[] = {
“PATH=/sbin:/bin”,
NULL
};
char *argv[] = {
“/sbin/modprobe”,
“-first-time”,
“e1000″,
NULL
};
if ((ret = call_usermodehelper(argv[0], argv, envp, 1)) != 0)
printk(KERN_ERR “Kmod test failed! (%d)\n”, ret);
return ret > 0 ? - ret : ret;
}
static void __exit kmod_exit(void)
{
}
module_init(kmod_init);
module_exit(kmod_exit);
MODULE_LICENSE(”GPL”);
用insmod插入它时实际上调用了用户态的modprobe插入另一个内核模块e1000。如果不希望将这个虚桩留在内核中，也可以通过在kmod_init中返回-1将自身从内核中移除。
验证结果表明这个虚桩式内核模块的方案完全是可行的，而且与被加载的实际内核模块之间没有任何耦合及影响，它们可以各自独立的被卸载。