[PATCH] rootfs (part 1)

[PATCH] rootfs (part 1)

[Alexander Viro]

	Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
and follow_dotdot. Real root is mounted atop of the "absolute" one.

	More interesting stuff lives in the next parts - once we
have rootfs we can get rid of a lot of cruft in fs/super.c around
mounting real root and switching it after initrd. In particular,
we can get rid of the umount_root flag in do_umount() and kill_super()
which allows much cleaner handling of vfsmounts. I'll try to feed this
stuff in small and obvious pieces.

	It's transparent to userland - the only visible effect is
an extra line in /proc/mounts. Moreover, it's transparent to the
kernel - the only functions that really care are those that do
the first mount.

	One point that might be better done differently - since we
need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
limits patches from -ac) we might be better off doing a minimal
variant permanently in kernel (calling it rootfs) and making
ramfs use rootfs methods. It's completely separate issue, so I've
done it the simplest way for the time being.

	And yes, patch got testing. Please, apply.
							Al

diff -urN S5-pre2-init/fs/Config.in S5-pre2-rootfs/fs/Config.in
--- S5-pre2-init/fs/Config.in	Sat Apr 28 02:12:55 2001
+++ S5-pre2-rootfs/fs/Config.in	Wed May 16 03:14:12 2001
@@ -32,7 +32,8 @@
 fi
 tristate 'Compressed ROM file system support' CONFIG_CRAMFS
 bool 'Virtual memory file system support (former shm fs)' CONFIG_TMPFS
-tristate 'Simple RAM-based file system support' CONFIG_RAMFS
+define_bool CONFIG_RAMFS y
+# tristate 'Simple RAM-based file system support' CONFIG_RAMFS
 
 tristate 'ISO 9660 CDROM file system support' CONFIG_ISO9660_FS
 dep_mbool '  Microsoft Joliet CDROM extensions' CONFIG_JOLIET $CONFIG_ISO9660_FS
diff -urN S5-pre2-init/fs/namei.c S5-pre2-rootfs/fs/namei.c
--- S5-pre2-init/fs/namei.c	Sat Apr 28 02:12:56 2001
+++ S5-pre2-rootfs/fs/namei.c	Wed May 16 02:06:02 2001
@@ -410,6 +410,8 @@
 		mntput(nd->mnt);
 		nd->mnt = parent;
 	}
+	while (d_mountpoint(nd->dentry) && __follow_down(&nd->mnt, &nd->dentry))
+		;
 }
 /*
  * Name resolution.
diff -urN S5-pre2-init/fs/super.c S5-pre2-rootfs/fs/super.c
--- S5-pre2-init/fs/super.c	Tue May 15 03:51:04 2001
+++ S5-pre2-rootfs/fs/super.c	Wed May 16 04:15:26 2001
@@ -1447,17 +1447,52 @@
 	return retval;
 }
 
-void __init mount_root(void)
+void __init mount_rootfs(void)
+{
+	struct file_system_type * fs_type;
+	struct super_block * sb;
+	struct vfsmount *vfsmnt;
+
+	fs_type = get_fs_type("ramfs");
+
+	if (!fs_type)
+		panic("ramfs not built in");
+
+	sb = get_sb_nodev(fs_type, 0, NULL);
+	put_filesystem(fs_type);
+
+	if (!sb) 
+		panic("unable to create rootfs");
+
+	vfsmnt = add_vfsmnt(NULL, sb->s_root, "rootfs");
+	if (!vfsmnt)
+		panic("can't create a single vfsmount");
+
+	up(&mount_sem);
+
+	set_fs_root(current->fs, vfsmnt, sb->s_root);
+	set_fs_pwd(current->fs, vfsmnt, sb->s_root);
+}
+
+void __init mount_root(char *to)
 {
 	struct file_system_type * fs_type;
 	struct super_block * sb;
 	struct vfsmount *vfsmnt;
 	struct block_device *bdev = NULL;
 	mode_t mode;
-	int retval;
+	int retval = 0;
 	void *handle;
 	char path[64];
 	int path_start = -1;
+	struct nameidata root_nd;
+
+	if (path_init(to, LOOKUP_POSITIVE|LOOKUP_DIRECTORY, &root_nd))
+		retval = path_walk(to, &root_nd);
+
+	if (retval)
+		panic("Where do I mount root?");
+
 
 #ifdef CONFIG_ROOT_NFS
 	void *data;
@@ -1591,10 +1626,11 @@
 		devfs_mk_symlink (NULL, "root", DEVFS_FL_DEFAULT,
 				  path + 5 + path_start, NULL, NULL);
 		memcpy (path + path_start, "/dev/", 5);
-		vfsmnt = add_vfsmnt(NULL, sb->s_root, path + path_start);
+		vfsmnt = add_vfsmnt(&root_nd, sb->s_root, path + path_start);
 	}
 	else
-		vfsmnt = add_vfsmnt(NULL, sb->s_root, "/dev/root");
+		vfsmnt = add_vfsmnt(&root_nd, sb->s_root, "/dev/root");
+	path_release(&root_nd);
 	/* FIXME: if something will try to umount us right now... */
 	if (vfsmnt) {
 		set_fs_root(current->fs, vfsmnt, sb->s_root);
@@ -1647,10 +1683,8 @@
 
 asmlinkage long sys_pivot_root(const char *new_root, const char *put_old)
 {
-	struct dentry *root;
-	struct vfsmount *root_mnt;
 	struct vfsmount *tmp;
-	struct nameidata new_nd, old_nd;
+	struct nameidata new_nd, old_nd, root_nd, parent_nd;
 	char *name;
 	int error;
 
@@ -1682,9 +1716,10 @@
 		goto out1;
 
 	read_lock(&current->fs->lock);
-	root_mnt = mntget(current->fs->rootmnt);
-	root = dget(current->fs->root);
+	root_nd.mnt = mntget(current->fs->rootmnt);
+	root_nd.dentry = dget(current->fs->root);
 	read_unlock(&current->fs->lock);
+
 	down(&mount_sem);
 	down(&old_nd.dentry->d_inode->i_zombie);
 	error = -ENOENT;
@@ -1695,7 +1730,7 @@
 	if (d_unhashed(old_nd.dentry) && !IS_ROOT(old_nd.dentry))
 		goto out2;
 	error = -EBUSY;
-	if (new_nd.mnt == root_mnt || old_nd.mnt == root_mnt)
+	if (new_nd.mnt == root_nd.mnt || old_nd.mnt == root_nd.mnt)
 		goto out2; /* loop */
 	error = -EINVAL;
 	tmp = old_nd.mnt; /* make sure we can reach put_old from new_root */
@@ -1714,15 +1749,20 @@
 		goto out3;
 	spin_unlock(&dcache_lock);
 
+	parent_nd.mnt = mntget(root_nd.mnt->mnt_parent);
+	parent_nd.dentry = dget(root_nd.mnt->mnt_mountpoint);
+
 	move_vfsmnt(new_nd.mnt, new_nd.dentry, NULL, NULL);
-	move_vfsmnt(root_mnt, old_nd.dentry, old_nd.mnt, NULL);
-	chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt);
+	move_vfsmnt(root_nd.mnt, old_nd.dentry, old_nd.mnt, NULL);
+	move_vfsmnt(new_nd.mnt, parent_nd.dentry, parent_nd.mnt, NULL);
+
+	path_release(&parent_nd);
+	chroot_fs_refs(root_nd.dentry,root_nd.mnt,new_nd.dentry,new_nd.mnt);
 	error = 0;
 out2:
 	up(&old_nd.dentry->d_inode->i_zombie);
 	up(&mount_sem);
-	dput(root);
-	mntput(root_mnt);
+	path_release(&root_nd);
 	path_release(&old_nd);
 out1:
 	path_release(&new_nd);
@@ -1760,8 +1800,13 @@
 		} else 
 			path_release(&devfs_nd);
 	}
+	/* chdir to the absolute root */
+	set_fs_pwd(current->fs, old_rootmnt->mnt_parent,
+				old_rootmnt->mnt_mountpoint);
+	/* detach initrd */
+	move_vfsmnt(old_rootmnt, old_rootmnt->mnt_root, NULL, NULL);
 	ROOT_DEV = new_root_dev;
-	mount_root();
+	mount_root(".");
 #if 1
 	shrink_dcache();
 	printk("change_root: old root has d_count=%d\n", 
@@ -1786,7 +1831,7 @@
 		printk(KERN_ERR "error %d\n", blivet);
 		return error;
 	}
-	/* FIXME: we should hold i_zombie on nd.dentry */
+	/* re-attach on put_old */
 	move_vfsmnt(old_rootmnt, nd.dentry, nd.mnt, "/dev/root.old");
 	mntput(old_rootmnt);
 	path_release(&nd);
diff -urN S5-pre2-init/include/linux/fs.h S5-pre2-rootfs/include/linux/fs.h
--- S5-pre2-init/include/linux/fs.h	Tue May 15 03:51:04 2001
+++ S5-pre2-rootfs/include/linux/fs.h	Wed May 16 03:24:37 2001
@@ -1308,7 +1308,8 @@
 
 
 extern void show_buffers(void);
-extern void mount_root(void);
+extern void mount_root(char *);
+extern void mount_rootfs(void);
 
 #ifdef CONFIG_BLK_DEV_INITRD
 extern kdev_t real_root_dev;
diff -urN S5-pre2-init/init/main.c S5-pre2-rootfs/init/main.c
--- S5-pre2-init/init/main.c	Wed May 16 07:48:49 2001
+++ S5-pre2-rootfs/init/main.c	Wed May 16 07:49:16 2001
@@ -706,6 +706,7 @@
 
 	start_context_thread();
 	do_initcalls();
+	mount_rootfs();
 
 #ifdef CONFIG_IRDA
 	irda_proto_init();
@@ -744,7 +745,7 @@
 #endif
 
 	/* Mount the root filesystem.. */
-	mount_root();
+	mount_root("/");
 
 	mount_devfs_fs ();
 

Re: [PATCH] rootfs (part 1)

[Christoph Rohland]

Hi Al,

On Wed, 16 May 2001, Alexander Viro wrote:
> 	One point that might be better done differently - since we
> need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
> as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
> limits patches from -ac) we might be better off doing a minimal
> variant permanently in kernel (calling it rootfs) and making
> ramfs use rootfs methods. It's completely separate issue, so I've
> done it the simplest way for the time being.

Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a
minimal _example_ fs. There was some agreement that this should stay
so.

Look into mm/shmem.c and look how little is added by CONFIG_TMPFS and
how much is duplicated from ramfs

If we really think the added swap vector per file in tmpfs is a major
overhead we should add the nonswapping functions there.

Greetings
		Christoph

Re: [PATCH] rootfs (part 1)

[Linus Torvalds]

On Wed, 16 May 2001, Alexander Viro wrote:
>
> 	Linus, patch is the first chunk of rootfs stuff. I've tried to
> get it as small as possible - all it does is addition of absolute root
> on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> and follow_dotdot. Real root is mounted atop of the "absolute" one.

Looks ok, but it also feels like 2.5.x stuff to me. 

Also, there's the question of whether to make ramfs just built-in, or make
_tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same
things and you need that one for shared mappings etc.

Comments?

		Linus

Re: [PATCH] rootfs (part 1)

[Christoph Rohland]

Hi Linus,

On Wed, 16 May 2001, Linus Torvalds wrote:
> Looks ok, but it also feels like 2.5.x stuff to me. 
> 
> Also, there's the question of whether to make ramfs just built-in,
> or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs
> does the same things and you need that one for shared mappings etc.
> 
> Comments?

cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
-rw-r--r--    1 cr       users      154652 Mai 16 19:27 mm/shmem.o-tmpfs
-rw-r--r--    1 cr       users      180764 Mai 16 19:24 mm/shmem.o+tmpfs
cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
-rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o

So CONFIG_TMPFS adds 26k and ramfs 140k.

Greetings
		Christoph

Re: [PATCH] rootfs (part 1)

[Jeff Garzik]

Christoph Rohland wrote:
> 
> Hi Linus,
> 
> On Wed, 16 May 2001, Linus Torvalds wrote:
> > Looks ok, but it also feels like 2.5.x stuff to me.
> >
> > Also, there's the question of whether to make ramfs just built-in,
> > or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs
> > does the same things and you need that one for shared mappings etc.
> >
> > Comments?
> 
> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
> -rw-r--r--    1 cr       users      154652 Mai 16 19:27 mm/shmem.o-tmpfs
> -rw-r--r--    1 cr       users      180764 Mai 16 19:24 mm/shmem.o+tmpfs
> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
> -rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o
> 
> So CONFIG_TMPFS adds 26k and ramfs 140k.

On what system?  I don't think this is a good measure...
> [jgarzik@rum linux_2_4]$ ls -l fs/ramfs/ramfs.o 
> -rw-r--r--    1 jgarzik  jgarzik      5830 May 15 09:29 fs/ramfs/ramfs.o
> [jgarzik@rum linux_2_4]$ ls -l mm/shmem.o (includes tmpfs)
> -rw-r--r--    1 jgarzik  jgarzik     17496 May 15 09:28 mm/shmem.o

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: [PATCH] rootfs (part 1)

[Linus Torvalds]

On 16 May 2001, Christoph Rohland wrote:
> 
> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
> -rw-r--r--    1 cr       users      154652 Mai 16 19:27 mm/shmem.o-tmpfs
> -rw-r--r--    1 cr       users      180764 Mai 16 19:24 mm/shmem.o+tmpfs
> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
> -rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o
> 
> So CONFIG_TMPFS adds 26k and ramfs 140k.

What the hell are you doing? Compiling with debugging or something?

The ramfs inode.o file (the only file that ramfs contains) has 376 bytes
of data and 1612 bytes of code. BYTES. The whole final object file with
all the relocation information is

	-rw-r--r--    1 torvalds eng          5734 May 16 10:58 ramfs.o

but out of that 5.5kB, only 2kB are actually linked into the kernel and
are used to _run_.

How do you get it to 140kB? You're doing something _seriously_
wrong. You're off by a factor of 70.

		Linus

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

On 16 May 2001, Christoph Rohland wrote:

> Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a
> minimal _example_ fs. There was some agreement that this should stay
> so.

Because what I need is an absolute minimum. Heck, I don't even use
regular files (in the full variant of patch, that is). They might
become useful, but I can live with mkdir() and mknod(). Moreover,
I want it mounted very early. Right now I'm doing that after initcalls,
but there's a very good reason to move the thing as early as possible.
So the fewer things it uses - the better.

Re: [PATCH] rootfs (part 1)

[David L. Parsley]

Linus Torvalds wrote:
> What the hell are you doing? Compiling with debugging or something?

I'll bet he's using a rootkit 'ls' that shows file sizes in bits.
;-)

regards,
	David

-- 
David L. Parsley
Network Administrator, Roanoke College
"If I have seen further it is by standing on ye shoulders of
Giants."
--Isaac Newton

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

On 16 May 2001, Christoph Rohland wrote:

> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
> -rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o

_What_?

Re: [PATCH] rootfs (part 1)

[Christoph Rohland]

Hi Linus,

On Wed, 16 May 2001, Linus Torvalds wrote:
> 
> On 16 May 2001, Christoph Rohland wrote:
>> 
>> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
>> -rw-r--r--    1 cr       users      154652 Mai 16 19:27 mm/shmem.o-tmpfs
>> -rw-r--r--    1 cr       users      180764 Mai 16 19:24 mm/shmem.o+tmpfs
>> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
>> -rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o
>> 
>> So CONFIG_TMPFS adds 26k and ramfs 140k.
> 
> What the hell are you doing? Compiling with debugging or something?

Yep, sorry that was uml with debugging info.

> The ramfs inode.o file (the only file that ramfs contains) has 376
> bytes of data and 1612 bytes of code. BYTES. The whole final object
> file with all the relocation information is
> 
> 	-rw-r--r-- 1 torvalds eng 5734 May 16 10:58 ramfs.o
> 
> but out of that 5.5kB, only 2kB are actually linked into the kernel
> and are used to _run_.

-rw-r--r--    1 root     root         8656 May 16 20:27 fs/ramfs/ramfs.o
-rw-r--r--    1 root     root        11688 May 16 20:24 mm/shmem.o-tmpfs
-rw-r--r--    1 root     root        18592 May 16 20:20 mm/shmem.o+tmpfs

That's an -ac kernel, so ramfs does accounting and is a little bigger
than yours.

So the read/write support in tmpfs is about the same size as ramfs.

Greetings
		Christoph

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

On Wed, 16 May 2001, Linus Torvalds wrote:

> 
> On Wed, 16 May 2001, Alexander Viro wrote:
> >
> > 	Linus, patch is the first chunk of rootfs stuff. I've tried to
> > get it as small as possible - all it does is addition of absolute root
> > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> > and follow_dotdot. Real root is mounted atop of the "absolute" one.
> 
> Looks ok, but it also feels like 2.5.x stuff to me. 

Umm... It might be, but
	* it makes fixing races in fs/super.c easier and we will need that
in 2.4 (or, at least, backported to 2.4 at some point)
	* it's backwards-compatible.
	* it allows to kill tons of the ugliness in rd.c in obviously
correct way, for values of obviously correct equal to "provably equivalent
behaviour to the old code"

I think that it's OK for 2.4, but then I'm obviously biased (mostly by
the fact that I know how much it allows to clean up without breaking any
compatibility, including binary compatibility in the kernel). Up to you,
indeed.
 
> Also, there's the question of whether to make ramfs just built-in, or make
> _tmpfs_ built in - ramfs is certainly simpler, but tmpfs does the same
> things and you need that one for shared mappings etc.
> 
> Comments?

Well, since all I actually use in the full variant of patch is sys_mknod(),
sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we
really need minimal rootfs in the kernel (no regular files) and let
ramfs, tmpfs, whatever-device-fs use it as a library.
								Al

Re: [PATCH] rootfs (part 1)

[Christoph Rohland]

Hi Alexander,

On Wed, 16 May 2001, Alexander Viro wrote:
> Because what I need is an absolute minimum. Heck, I don't even use
> regular files (in the full variant of patch, that is). They might
> become useful, but I can live with mkdir() and mknod().

So what about adding shmem_mknod and shmem_mkdir to the core shmem.c
part? They are now under CONFIG_TMPFS but are only ~20 lines of code.

Greetings
		Christoph

Re: [PATCH] rootfs (part 1)

[H. Peter Anvin]

Followup to:  <Pine.GSO.4.21.0105161434420.26191-100000@weyl.math.psu.edu>
By author:    Alexander Viro <viro@math.psu.edu>
In newsgroup: linux.dev.kernel
> 
> Well, since all I actually use in the full variant of patch is sys_mknod(),
> sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we
> really need minimal rootfs in the kernel (no regular files) and let
> ramfs, tmpfs, whatever-device-fs use it as a library.
> 

One thing that I thought was really spiffy was someone who had done
patches to populate a ramfs from a tarball loaded via the initrd
bootloader protocol... call it "initial ramfs."  It allowed a whole
lot of cleanup -- the "initrd" isn't magic anymore (instead use
pivot_root), and it gets rid of the rd stuff.  At the same time it
does allow the full flexibility of a fullblown filesystem that can be
populated with arbitrary contents.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

On 16 May 2001, H. Peter Anvin wrote:

> Followup to:  <Pine.GSO.4.21.0105161434420.26191-100000@weyl.math.psu.edu>
> By author:    Alexander Viro <viro@math.psu.edu>
> In newsgroup: linux.dev.kernel
> > 
> > Well, since all I actually use in the full variant of patch is sys_mknod(),
> > sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we
> > really need minimal rootfs in the kernel (no regular files) and let
> > ramfs, tmpfs, whatever-device-fs use it as a library.
> > 
> 
> One thing that I thought was really spiffy was someone who had done
> patches to populate a ramfs from a tarball loaded via the initrd
> bootloader protocol... call it "initial ramfs."  It allowed a whole
> lot of cleanup -- the "initrd" isn't magic anymore (instead use
> pivot_root), and it gets rid of the rd stuff.  At the same time it
> does allow the full flexibility of a fullblown filesystem that can be
> populated with arbitrary contents.

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.

So late-boot stuff (mounting root, unpacking initrd, mounting devfs if
asked to, loading initrd from floppies,  moving initrd around - the whole
whorehouse) is actually done by sane, normal system calls. And it's
very easy to expand - I refused to apply any fancy patches simply because
I wanted 100% compatibility with all existing boot setups, no matter
how silly they are. If behaviour is absent in Linus' tree - sorry.
However, playing with that stuff becomes much easier - essentially it's
a userland code. You have an empty, writable fs, your root and cwd are
on it, you can do any system calls you want.

So if you want this untar-into-ramfs - well, more power to you. I'd
recommend to use a separate instance of ramfs for that, though, so that
you could easily get rid of it afterwards. Again, at that point you
have normal userland environment, so doing whatever you want to do
doesn't require any kernel-specific stuff. Write as if you were adding
your code to the beginning of /sbin/init.

Re: [PATCH] rootfs (part 1)

[H. Peter Anvin]

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?

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

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.

Re: [PATCH] rootfs (part 1)

[Alan Cox]

> 	Linus, patch is the first chunk of rootfs stuff. I've tried to
> get it as small as possible - all it does is addition of absolute root
> on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> and follow_dotdot. Real root is mounted atop of the "absolute" one.

Surely this is getting right into 2.5 stuff. 

Re: [PATCH] rootfs (part 1)

[Alan Cox]

> Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a
> minimal _example_ fs. There was some agreement that this should stay
> so.

I think ramfs is an incredibly flawed example right now - precisely because
it has no error cases. ramfs with the size limiting is a brilliant fs for
embedded/pda work as well as an example that shows error paths

Re: [PATCH] rootfs (part 1)

[Alan Cox]

> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
> -rw-r--r--    1 cr       users      154652 Mai 16 19:27 mm/shmem.o-tmpfs
> -rw-r--r--    1 cr       users      180764 Mai 16 19:24 mm/shmem.o+tmpfs
> cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
> -rw-r--r--    1 cr       users      141452 Mai 16 19:27 fs/ramfs/ramfs.o
> 
> So CONFIG_TMPFS adds 26k and ramfs 140k.

I think you have a major tool problem.

bash-2.04$ size mm/shmem.o
   text	   data	    bss	    dec	    hex	filename
   7422	    572	      0	   7994	   1f3a	mm/shmem.o
bash-2.04$ size fs/ramfs/ramfs.o 
   text	   data	    bss	    dec	    hex	filename
   3185	    368	      0	   3553	    de1	fs/ramfs/ramfs.o

Never trust ls -l size for binaries, its very very unrelated.

So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac.

Re: [PATCH] rootfs (part 1)

[Alexander Viro]

On Thu, 17 May 2001, Alan Cox wrote:

> > 	Linus, patch is the first chunk of rootfs stuff. I've tried to
> > get it as small as possible - all it does is addition of absolute root
> > on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
> > and follow_dotdot. Real root is mounted atop of the "absolute" one.
> 
> Surely this is getting right into 2.5 stuff. 

Maybe. I still think that it's local enough to be tolerable in 2.4, but
postponing it until 2.5 is not a big deal. I'll put that (and the rest
of rootfs stuff) on anonftp and post CFT. I'd appreciate review of
that code once the splitup is done, if you have time for that.

Re: [PATCH] rootfs (part 1)

[Christoph Rohland]

Hi Alan,

On Thu, 17 May 2001, Alan Cox wrote:
> I think you have a major tool problem.
> 
> bash-2.04$ size mm/shmem.o
>    text	   data	    bss	    dec	    hex	filename
>    7422	    572	      0	   7994	   1f3a	mm/shmem.o
> bash-2.04$ size fs/ramfs/ramfs.o 
>    text	   data	    bss	    dec	    hex	filename
>    3185	    368	      0	   3553	    de1	fs/ramfs/ramfs.o
> 
> Never trust ls -l size for binaries, its very very unrelated.
> 
> So ramfs is 3553 bytes, shmem.o in total is 8K on current -ac.

But you cannot disable shmem.o totally. That's my whole point in the
discussion. Why add something what is mostly included in the kernel
already?

You have to compare shmem with tmpfs against shmem w/o it:

   text    data     bss     dec     hex filename
   3398     376       0    3774     ebe fs/ramfs/ramfs.o
   5150     484       0    5634    1602 mm/shmem.o
   9174     636       0    9810    2652 mm/shmem.o+tmpfs

So tmpfs is 400 Bytes bigger than ramfs. 

If you add the correct timestamp handling the difference will go down
further. And we gain functionality, don't we?

Greetings
		Christoph