Re: another (!) new kmod.c

Adam J. Richter (adam@yggdrasil.com)
Fri, 17 Apr 1998 19:54:02 -0700


Mikael Pettersson wrote:
>Thinking further about this, I think the following changes to
>Adam's version should fix this problem: in exec_modprobe(),
>1. nullify current->fs
>2. set current->fs to reference that of init/kswapd/et al
>3. remove the stat() call
>4. execve() modprobe.
>
>This should (unless I'm missing something) eliminate the chroot problem.
>I'll try to work out a concrete patch this weekend.

Earlier today, I wrote that I was bascically neutral about this.
After reading other postings and thinking about the issue more
myself, I am now in favor "kmod follows init's root" because:

1. I think that we probably would get obscure unrepeatable
technical suppot problems related to anonymous FTP otherwise.

2. I also realize that while putting kernel modules in the
anonymous FTP area is something like the situation with
shared libraries, new kernels are released every couple
of days, while new C libraries are released roughly
monthly. (How's that for a statement about free
software development cycles?)

3. I would rather not have to worry about accidental
contamination of the kernel from other chroot'ed
environments (e.g., I accidentally load an outdated
iBCS module).

4. If we're going to develop some kind of "modprobe -r -a"
to run help programs before unloading modules, this will
probably do the wrong thing with modules loaded from
alternative roots.

Your change may mean that in order for a ramdisk that uses
"exec chroot /mnt /sbin/init" to work with modprobe, the ramdisk
program will have to be named /sbin/init instead of /linuxrc and the
kernel's "real root" field will have to be set to the ramdisk, but that's
a stylistic change I've wanted to make to our ramdisks anyhow.

Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."

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