[lkml]   [2001]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] rootfs (part 1)

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.032 / U:1.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site