initramfs: Allow rootfs to use tmpfs instead of ramfs

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

+ This option switches rootfs so that it uses tmpfs rather than ramfs
+ for its file storage. This makes rootfs swappable so having a large
+ initrd or initramfs image won't eat up valuable RAM.

This patch is based on John Zielinski's
http://marc.theaimsgroup.com/?l=linux-kernel&m=107013630212011&w=4 patch.

Modified for 2.6.17.

RunTime tested on i386.

This trivial patch should go into 2.6.18.

Cc <[email protected]>

Cc Chris Wright <[email protected]>

drivers/block/Kconfig +7 -0

+	  initrd or initramfs image won't eat up valuable RAM.
+
+config RAMFS_ROOTFS
+	bool 
+	depends on !SHM_ROOTFS
+	default y
+	select RAMFS
 
 config CDROM_PKTCDVD
 	tristate "Packet writing on CD/DVD media"

fs/Kconfig +1 -1

@@ -853,7 +853,7 @@ config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
 config RAMFS
-	bool
+	tristate "Ramfs file system support"
 	default y
 	---help---
 	  Ramfs is a file system which keeps all files in RAM. It allows

fs/ramfs/inode.c +7 -0

@@ -191,22 +191,27 @@ struct super_block *ramfs_get_sb(struct 
 	return get_sb_nodev(fs_type, flags, data, ramfs_fill_super);
 }
 
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
 	int flags, const char *dev_name, void *data)
 {
 	return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
 }
+#endif
 
 static struct file_system_type ramfs_fs_type = {
 	.name		= "ramfs",
 	.get_sb		= ramfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct file_system_type rootfs_fs_type = {
 	.name		= "rootfs",
 	.get_sb		= rootfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#endif
 
 static int __init init_ramfs_fs(void)
 {

@@ -221,9 +226,11 @@ static void __exit exit_ramfs_fs(void)
 module_init(init_ramfs_fs)
 module_exit(exit_ramfs_fs)
 
+#ifdef CONFIG_RAMFS_ROOTFS
 int __init init_rootfs(void)
 {
 	return register_filesystem(&rootfs_fs_type);
 }
+#endif
 
 MODULE_LICENSE("GPL");

mm/shmem.c +13 -0

+		shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
+					sizeof(struct shmem_inode_info),
+					0, 0, init_once, NULL);
+		if (shmem_inode_cachep == NULL)
+			return -ENOMEM;
+	}
 	return 0;
 }
 

@@ -2345,6 +2347,27 @@ put_memory:
 	return ERR_PTR(error);
 }
 
+#ifdef CONFIG_SHM_ROOTFS
+static struct super_block *rootfs_get_sb(struct file_system_type *fs_type,
+	int flags, const char *dev_name, void *data)
+{
+	return get_sb_single(fs_type, flags, data, shmem_fill_super);
+}
+

mm/shmem.c +4 -0

+	return register_filesystem(&rootfs_fs_type);
+}
+#endif
+
 /*
  * shmem_zero_setup - setup a shared anonymous mapping
  *

Quoted 1 line · Al Boldi

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

Why? Looking further down we see what you should have explained here:

Quoted 3 lines

+ This option switches rootfs so that it uses tmpfs rather than ramfs
+ for its file storage. This makes rootfs swappable so having a large
+ initrd or initramfs image won't eat up valuable RAM.

Now, I'm far from an expert on initramfs and early userspace, but my understanding is that the "init" of a (properly designed) initramfs would pretty much "rm -rf" everything in the initramfs before passing control to the final "init". So (almost?) no valuable RAM is eaten up, nor the less valuable swap if you do extend this to tmpfs (unless something gets left open, which I think should not be the case).

So I'm inclined to say that this patch is simply unnecessary. But if people who know better think it's a good thing, I've no objection (though I've not tried it): the Kconfiggery looks more likely to provoke argument than the tmpfs/ramfs mods.

Quoted 15 lines · Hugh Dickins

Quoted 1 line · Al Boldi

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

Why? Looking further down we see what you should have explained here:

Quoted 3 lines

+ This option switches rootfs so that it uses tmpfs rather than ramfs
+ for its file storage. This makes rootfs swappable so having a large
+ initrd or initramfs image won't eat up valuable RAM.

Now, I'm far from an expert on initramfs and early userspace, but my understanding is that the "init" of a (properly designed) initramfs would pretty much "rm -rf" everything in the initramfs before passing control to the final "init". So (almost?) no valuable RAM is eaten up, nor the less valuable swap if you do extend this to tmpfs (unless something gets left open, which I think should not be the case).

Quoted 4 lines

So I'm inclined to say that this patch is simply unnecessary. But if people who know better think it's a good thing, I've no objection (though I've not tried it): the Kconfiggery looks more likely to provoke argument than the tmpfs/ramfs mods.

Well...

There is some justification: embedded people would like to load inittmpfs and then continue running.

The main issue -- which I am not sure what effect this patch has -- is that we would really like to move initramfs initialization even earlier in the kernel, so that it can include firmware loading for built-in device drivers, for example.

Thus, if this patch makes it harder to push initramfs initialization earlier, it's probably a bad thing.

If not, the author of the patch
really needs to explain why it works and why it doesn't add new dependencies to the initialization order.

Saying "this is a trivial patch" and pushing it on the -stable tree doesn't inspire too much confidence, as initialization is subtle.

Quoted 5 lines

The main issue -- which I am not sure what effect this patch has -- is that we would really like to move initramfs initialization even earlier in the kernel, so that it can include firmware loading for built-in device drivers, for example.

I suspect, if there would be a problem with tmpfs, then ramfs would be no different.

Quoted 2 lines

Thus, if this patch makes it harder to push initramfs initialization earlier, it's probably a bad thing.

Agreed, but remember that tmpfs is an option, not a replacement.

Quoted 6 lines

If not, the author of the patch
really needs to explain why it works and why it doesn't add new dependencies to the initialization order.

Saying "this is a trivial patch" and pushing it on the -stable tree doesn't inspire too much confidence, as initialization is subtle.

Ok, I did play with main.c, and as you mentioned, initialization is subtle. But categorizing this patch as trivial is based more on the fact, that ramfs and tmpfs are semantically equivalent, and as such should not impose additional dependencies.

There is some justification: embedded people would like to load inittmpfs and then continue running.

The main issue -- which I am not sure what effect this patch has -- is that we would really like to move initramfs initialization even earlier in the kernel, so that it can include firmware loading for built-in device drivers, for example.

Thus, if this patch makes it harder to push initramfs initialization earlier, it's probably a bad thing. If not, the author of the patch really needs to explain why it works and why it doesn't add new dependencies to the initialization order.

Saying "this is a trivial patch" and pushing it on the -stable tree doesn't inspire too much confidence, as initialization is subtle.

-hpa

Quoted 1 line · Al Boldi

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

Why? Looking further down we see what you should have explained here:

Quoted 3 lines

+ This option switches rootfs so that it uses tmpfs rather than ramfs
+ for its file storage. This makes rootfs swappable so having a large
+ initrd or initramfs image won't eat up valuable RAM.

Now, I'm far from an expert on initramfs and early userspace, but my understanding is that the "init" of a (properly designed) initramfs would pretty much "rm -rf" everything in the initramfs before passing control to the final "init". So (almost?) no valuable RAM is eaten up, nor the less valuable swap if you do extend this to tmpfs (unless something gets left open, which I think should not be the case).

So I'm inclined to say that this patch is simply unnecessary. But if people who know better think it's a good thing, I've no objection (though I've not tried it): the Kconfiggery looks more likely to provoke argument than the tmpfs/ramfs mods.

Quoted 9 lines

This patch is based on John Zielinski's
http://marc.theaimsgroup.com/?l=linux-kernel&m=107013630212011&w=4
patch.

Modified for 2.6.17.

RunTime tested on i386.

This trivial patch should go into 2.6.18.

Well...

Quoted 2 lines

Cc <[email protected]>

Cc Chris Wright <[email protected]>

Umm, the -stable tree doesn't usually take enhancements, even if you think it's a very stable enhancement.

Quoted 11 lines

Cc Andrew Morton <[email protected]>

Cc John Zielinski <[email protected]>

Signed-off-by Al Boldi <[email protected]>

---

drivers/block/Kconfig +0 -0

@@ -412,6 +412,22 @@ config BLK_DEV_INITRD
 	  If RAM disk support (BLK_DEV_RAM) is also included, this
 	  also enables initial RAM disk (initrd) support.
 

drivers/block/Kconfig config BLK_DEV_INITRD · line 415

Quoted 1 line

drivers/block/Kconfig +1 -0

+config SHM_ROOTFS

Please say TMPFS_ROOTFS rather than SHM_ROOTFS throughout.

drivers/block/Kconfig config BLK_DEV_INITRD · line 420

Quoted 5 lines

drivers/block/Kconfig +5 -0

+	bool "Use tmpfs (shm) instead of ramfs for rootfs"
+	depends on BLK_DEV_INITRD
+	default n
+	select TMPFS
+	select SHMEM

Selects can be troublesome, but you may well have decided right.

Quoted 4 lines

drivers/block/Kconfig +3 -0

+	help
+	  This option switches rootfs so that it uses tmpfs rather than ramfs
+	  for it's file storage.  This makes rootfs swappable so having a

large

its

Quoted 69 lines

drivers/block/Kconfig +7 -0

+	  initrd or initramfs image won't eat up valuable RAM.
+
+config RAMFS_ROOTFS
+	bool
+	depends on !SHM_ROOTFS
+	default y
+	select RAMFS
 
 config CDROM_PKTCDVD
 	tristate "Packet writing on CD/DVD media"

fs/Kconfig +1 -1

@@ -853,7 +853,7 @@ config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
 config RAMFS
-	bool
+	tristate "Ramfs file system support"
 	default y
 	---help---
 	  Ramfs is a file system which keeps all files in RAM. It allows

fs/ramfs/inode.c +7 -0

@@ -191,22 +191,27 @@ struct super_block *ramfs_get_sb(struct
 	return get_sb_nodev(fs_type, flags, data, ramfs_fill_super);
 }
 
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct super_block *rootfs_get_sb(struct file_system_type
 *fs_type, int flags, const char *dev_name, void *data)
 {
 	return get_sb_nodev(fs_type, flags|MS_NOUSER, data, ramfs_fill_super);
 }
+#endif
 
 static struct file_system_type ramfs_fs_type = {
 	.name		= "ramfs",
 	.get_sb		= ramfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+
+#ifdef CONFIG_RAMFS_ROOTFS
 static struct file_system_type rootfs_fs_type = {
 	.name		= "rootfs",
 	.get_sb		= rootfs_get_sb,
 	.kill_sb	= kill_litter_super,
 };
+#endif
 
 static int __init init_ramfs_fs(void)
 {

@@ -221,9 +226,11 @@ static void __exit exit_ramfs_fs(void)
 module_init(init_ramfs_fs)
 module_exit(exit_ramfs_fs)
 
+#ifdef CONFIG_RAMFS_ROOTFS
 int __init init_rootfs(void)
 {
 	return register_filesystem(&rootfs_fs_type);
 }
+#endif
 
 MODULE_LICENSE("GPL");

mm/shmem.c +0 -0

@@ -2123,7 +2123,7 @@ failed:
 	return err;
 }
 

mm/shmem.c failed: · line 2126

Quoted 2 lines

mm/shmem.c +1 -1

-static struct kmem_cache *shmem_inode_cachep;
+static struct kmem_cache *shmem_inode_cachep = NULL;

No need to initialize static variables to 0 (or is someone going to raise the spectre of NULL being non-0 on some future architecture?)

mm/shmem.c static void init_once(void *foo, struct · line 2159

Quoted 12 lines

mm/shmem.c +1 -5

 static struct inode *shmem_alloc_inode(struct super_block *sb)
 {

@@ -2156,11 +2156,13 @@ static void init_once(void *foo, struct
 
 static int init_inodecache(void)
 {
-	shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
-				sizeof(struct shmem_inode_info),
-				0, 0, init_once, NULL);
-	if (shmem_inode_cachep == NULL)
-		return -ENOMEM;
+	if(!shmem_inode_cachep) {

        if (shmem_inode_cachep == NULL) {

is more consistent with the nearby style

Quoted 25 lines

mm/shmem.c +17 -0

+		shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
+					sizeof(struct shmem_inode_info),
+					0, 0, init_once, NULL);
+		if (shmem_inode_cachep == NULL)
+			return -ENOMEM;
+	}
 	return 0;
 }
 

@@ -2345,6 +2347,27 @@ put_memory:
 	return ERR_PTR(error);
 }
 
+#ifdef CONFIG_SHM_ROOTFS
+static struct super_block *rootfs_get_sb(struct file_system_type
 *fs_type, +	int flags, const char *dev_name, void *data)
+{
+	return get_sb_single(fs_type, flags, data, shmem_fill_super);
+}
+
+static struct file_system_type rootfs_fs_type = {
+	.name		= "rootfs",
+	.get_sb		= rootfs_get_sb,
+	.kill_sb	= kill_litter_super,
+};

mm/shmem.c put_memory: · line 2366

Quoted 5 lines

mm/shmem.c +5 -0

+
+int __init init_rootfs(void)
+{
+	if (init_inodecache())
+		panic("Can't initialize shm inode cache");

"tmpfs inode cache"
or "shmem inode cache"

mm/shmem.c put_memory: · line 2373

Quoted 7 lines

mm/shmem.c +4 -0

+	return register_filesystem(&rootfs_fs_type);
+}
+#endif
+
 /*
  * shmem_zero_setup - setup a shared anonymous mapping
  *

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

This patch is based on John Zielinski's
http://marc.theaimsgroup.com/?l=linux-kernel&m=107013630212011&w=4 patch.

Modified for 2.6.17.

RunTime tested on i386.

This trivial patch should go into 2.6.18.

Quoted 6 lines · Al Boldi

Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

This patch is based on John Zielinski's
http://marc.theaimsgroup.com/?l=linux-kernel&m=107013630212011&w=4
patch.

Quoted 5 lines

Modified for 2.6.17.

RunTime tested on i386.

This trivial patch should go into 2.6.18.

This looks like a new feature. What problem does it fix that would make it acceptable to add to the -stable tree?

Well, ramfs has some pitfalls, which doesn't make it suitable for a long-lived rootfs. OTOH, tmpfs is much more mature, while semantically the same.

Being semantically the same, while not exhibiting ramfs pitfalls, makes it suitable to be pushed into the -stable tree, IMHO.

Quoted 6 lines · Al Boldi

Well, ramfs has some pitfalls, which doesn't make it suitable for a long-lived rootfs. OTOH, tmpfs is much more mature, while semantically the same.

Being semantically the same, while not exhibiting ramfs pitfalls, makes it suitable to be pushed into the -stable tree, IMHO.

This is total nonsense.

They're very different from an implementation standpoint.

Quoted 4 lines

Quoted 3 lines

Being semantically the same, while not exhibiting ramfs pitfalls, makes it suitable to be pushed into the -stable tree, IMHO.

This is total nonsense.

Are you sure?

Quoted 1 line

They're very different from an implementation standpoint.

Think ext2/3.

Being semantically the same, while not exhibiting ramfs pitfalls, makes it suitable to be pushed into the -stable tree, IMHO.

Quoted 2 lines · * Al Boldi ([email protected]) wrote:

Being semantically the same, while not exhibiting ramfs pitfalls, makes it suitable to be pushed into the -stable tree, IMHO.

You are failing to show how this is a critical type bugfix for -stable. We are picky about -stable additions because we don't want to undermine the value of the -stable tree.