On Wed, 16 May 2001, H. Peter Anvin wrote:
> Alexander Viro wrote:
> >
> > In full variant of patch I don't _have_ mount_root(9). It's done by
> > mount(2). Period. Initrd or not. Notice that rootfs stays absolute root
> > forever - it's much more convenient for fs/super.c, since you can get rid
> > of many kludges that way. So I'm not too happy about populating rootfs with
> > tons of files. BTW, loading initrd is done by open(2), read(2) and write(2) -
> > none of this fake struct file business anymore.
> >
>
> OK, I see what you're doing now. However, I'm confused what you mean
> with "rootfs stays absolute root forever" -- does that mean that you
> mount the new root on top of /, and so the rootfs remains in the system
> never to be reclaimed, as opposed to pivot_root-ing it?
Yes. Pivot_root works, all right, but it rotates (your process' root, old, new).
So it works in chroot correctly now. And since we chroot out of the
absolute root when we mount initrd (or final root, for that matter) any
setup that used pivot_root keeps working as it did.
As for "never to be reclaimed"... Let's see:
1 struct super_block
1 struct vfsmount
couple of struct dentry
couple of struct inode
(for values of couple from 1 to 4; we can reduce it to 1 but I didn't bother
with that; all it takes is a couple of calls of sys_rmdir()/sys_unlink()).
Compared to the amount of space we free in .code of fs/super.c it's noise.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:20 EST