That will, unfortunately, not release the initrd memory. Although I
like the concept of having initrd mount the future root explicitly,
the pivot from the initrd root to the new system root is an operation
which is fundamentally different from a chroot, because the pivot
requires that the old (initrd) root is unmounted (and in the case of
an initrd, destroyed, but that's a function of the device driver.)
If we want to do the "initrd mounts the new root" method, the initrd
transition code suddenly becomes a matter of picking the filesystem
hierarchy (dentry tree) apart at the pivot point so that the old root
can be destroyed, and then reestablished with a new root. It's
doable, but tricky, and is nothing like what chroot does.
The advantage is that we don't have to have yet another interface for
mounting filesystems, and that you won't run into a wall if you want
to, say, make your root an smb filesystem (once Samba and Linux
support the new Unix extensions to SMB/CIFS, it won't be as crazy as
it sounds.)
As far as kmod is concerned, I rather strongly feel the right thing to
do is to always spawn from the system root.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu