Linux-kernel mailing list archive 1998-10,: Re: pre-2.1.90.. (kmod fix)

# Re: pre-2.1.90.. (kmod fix)

Kirk Petersen (kirk@eidolon.speakeasy.org)
Fri, 13 Mar 1998 12:06:55 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Benjamin Saller Bender: "Re: [patch] x86, small syscall entry speedup, 2.1.90"
- Previous message: Gerard Roudier: "Re: MD raid speed going down...."

> Why not try to fork out of the call to request_module?

That was my first approach. It didn't work, but that was a long
time ago and I now know a lot more about the kernel. So, I'm trying to
move the fork/clone/kernel_thread into request_module again. It cleans
things up a lot, and I imagine it would fix the module-loading-modules
problem. After spending most of last night trying this, I reached the
following pseudo-code/conclusions:

request_module(char * name)
{
int pid;

pid = kernel_thread(loader, name, 0);

waitpid(pid, NULL, __WCLONE);
}

loader(void * name)
{
char * argv[] = { "modprobe", "-k", name, NULL };
char * envp[] = { stuff };

execve(modprobe_path, argv, envp);

/* if we reach this, bad news! */
printk("error!\n");
_exit(0);
}

request_module() works just fine (after learning about the
__WCLONE option, that is). The problem is with the execve(). It just
doesn't happen. Unfortunatly, I didn't get a chance to test the return
value or anything.
Any ideas?

    --
    Kirk Petersen
    speakeasy.org/~kirk/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

- Next message: Benjamin Saller Bender: "Re: [patch] x86, small syscall entry speedup, 2.1.90"
- Previous message: Gerard Roudier: "Re: MD raid speed going down...."