[PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[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.

Modified for 2.6.17.

RunTime tested on i386.

This trivial patch should go into 2.6.18.

Cc: <stable@kernel.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Andrew Morton <akpm@osdl.org>
Cc: John Zielinski <grim@undead.cc>
Signed-off-by: Al Boldi <a1426z@gawab.com>

---
--- a/drivers/block/Kconfig	2006-07-30 16:44:59.000000000 +0300
+++ b/drivers/block/Kconfig	2006-07-30 16:45:53.000000000 +0300
@@ -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.
 
+config SHM_ROOTFS
+	bool "Use tmpfs (shm) instead of ramfs for rootfs"
+	depends on BLK_DEV_INITRD
+	default n
+	select TMPFS
+	select SHMEM
+	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
+	  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"
--- a/fs/Kconfig	2006-07-30 16:45:25.000000000 +0300
+++ b/fs/Kconfig	2006-07-30 16:46:36.000000000 +0300
@@ -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
--- a/fs/ramfs/inode.c	2006-07-30 16:45:37.000000000 +0300
+++ b/fs/ramfs/inode.c	2006-07-30 16:46:36.000000000 +0300
@@ -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");
--- a/mm/shmem.c	2006-07-30 16:45:54.000000000 +0300
+++ b/mm/shmem.c	2006-07-30 16:47:11.000000000 +0300
@@ -2123,7 +2123,7 @@ failed:
 	return err;
 }
 
-static struct kmem_cache *shmem_inode_cachep;
+static struct kmem_cache *shmem_inode_cachep = NULL;
 
 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) {
+		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,
+};
+
+int __init init_rootfs(void)
+{
+	if (init_inodecache())
+		panic("Can't initialize shm inode cache");
+	return register_filesystem(&rootfs_fs_type);
+}
+#endif
+
 /*
  * shmem_zero_setup - setup a shared anonymous mapping
  *

--

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Hugh Dickins]

On Sun, 30 Jul 2006, Al Boldi wrote:
> 
> Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.

Why?  Looking further down we see what you should have explained here:
> + 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.

> 
> 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...

> 
> Cc: <stable@kernel.org>
> Cc: Chris Wright <chrisw@sous-sol.org>

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

> Cc: Andrew Morton <akpm@osdl.org>
> Cc: John Zielinski <grim@undead.cc>
> Signed-off-by: Al Boldi <a1426z@gawab.com>
> 
> ---
> --- a/drivers/block/Kconfig	2006-07-30 16:44:59.000000000 +0300
> +++ b/drivers/block/Kconfig	2006-07-30 16:45:53.000000000 +0300
> @@ -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.
>  
> +config SHM_ROOTFS

Please say TMPFS_ROOTFS rather than SHM_ROOTFS throughout.

> +	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.

> +	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

> +	  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"
> --- a/fs/Kconfig	2006-07-30 16:45:25.000000000 +0300
> +++ b/fs/Kconfig	2006-07-30 16:46:36.000000000 +0300
> @@ -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
> --- a/fs/ramfs/inode.c	2006-07-30 16:45:37.000000000 +0300
> +++ b/fs/ramfs/inode.c	2006-07-30 16:46:36.000000000 +0300
> @@ -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");
> --- a/mm/shmem.c	2006-07-30 16:45:54.000000000 +0300
> +++ b/mm/shmem.c	2006-07-30 16:47:11.000000000 +0300
> @@ -2123,7 +2123,7 @@ failed:
>  	return err;
>  }
>  
> -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?)

>  
>  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

> +		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,
> +};
> +
> +int __init init_rootfs(void)
> +{
> +	if (init_inodecache())
> +		panic("Can't initialize shm inode cache");

                                        "tmpfs inode cache"
                                     or "shmem inode cache"

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

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[H. Peter Anvin]

Hugh Dickins wrote:
> On Sun, 30 Jul 2006, Al Boldi wrote:
>> Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.
> 
> Why?  Looking further down we see what you should have explained here:
>> + 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.
> 

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.

	-hpa

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Al Boldi]

H. Peter Anvin wrote:
> Hugh Dickins wrote:
> > On Sun, 30 Jul 2006, Al Boldi wrote:
> >> Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.
> >
> > Why?  Looking further down we see what you should have explained here:
> >> + 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.
>
> 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.

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

> 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.

> 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.


Thanks for your comments!

--
Al

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[H. Peter Anvin]

Al Boldi wrote:
>>
>> 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.
> 

That is a very bold assumption (a.k.a. "just plain wrong".)  ramfs and 
tmpfs are a lot more different than one would normally think from a 
kernel internals perspective.

>> 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.

Red herring.  If it goes in, it needs to be supportable going forward.

>> 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.

Again, that's just plain wrong.

	-hpa

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Rob Landley]

I am totally out of the loop here.  (BusyBox has been taking up all my time 
for months now...)

I thought rootfs already would be tmpfs whenever that was compiled into the 
kernel, but I suspect the kernel I was looking at to come to that conclusion 
wasn't vanilla.  Still, that implies this isn't the first patch out there to 
do this...

On Sunday 30 July 2006 2:48 pm, H. Peter Anvin wrote:
> There is some justification: embedded people would like to load 
> inittmpfs and then continue running.

Yup.  Embedded people who generally have no swap anyway.  (Swap to flash is a 
bad idea.)  However, I believe what they were after was the ability to limit 
the filesystem size so runaway logs don't trigger the OOM killer.

> 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 remember this was "pending" late last year.  Thought it had made it into 
2.6.16 or so.  I need _way_ more time to read the kernel list.  (I'm 50,197 
messages behind.  That's just silly...)

> 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.

It doesn't look like -stable material to me either.  It might be small enough 
to add to the current -devel cycle, but that's not my call.

Is there any current documentation on the kernel's init sequence other than 
reading init/main.c and friends?

> 	-hpa

Rob
-- 
Never bet against the cheap plastic solution.

Re: [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Al Boldi]

Hugh Dickins wrote:
> On Sun, 30 Jul 2006, Al Boldi wrote:
> > Replugs rootfs to use tmpfs instead of ramfs as a Kconfig option.
>
> Why?  Looking further down we see what you should have explained here:
> > + 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.
>
> > 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...
>
> > Cc: <stable@kernel.org>
> > Cc: Chris Wright <chrisw@sous-sol.org>
>
> Umm, the -stable tree doesn't usually take enhancements,
> even if you think it's a very stable enhancement.
>
> > Cc: Andrew Morton <akpm@osdl.org>
> > Cc: John Zielinski <grim@undead.cc>
> > Signed-off-by: Al Boldi <a1426z@gawab.com>
> >
> > ---
> > --- a/drivers/block/Kconfig	2006-07-30 16:44:59.000000000 +0300
> > +++ b/drivers/block/Kconfig	2006-07-30 16:45:53.000000000 +0300
> > @@ -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.
> >
> > +config SHM_ROOTFS
>
> Please say TMPFS_ROOTFS rather than SHM_ROOTFS throughout.

Ok.

> > +	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.
>
> > +	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

Yes.

> > +	  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"
> > --- a/fs/Kconfig	2006-07-30 16:45:25.000000000 +0300
> > +++ b/fs/Kconfig	2006-07-30 16:46:36.000000000 +0300
> > @@ -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
> > --- a/fs/ramfs/inode.c	2006-07-30 16:45:37.000000000 +0300
> > +++ b/fs/ramfs/inode.c	2006-07-30 16:46:36.000000000 +0300
> > @@ -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");
> > --- a/mm/shmem.c	2006-07-30 16:45:54.000000000 +0300
> > +++ b/mm/shmem.c	2006-07-30 16:47:11.000000000 +0300
> > @@ -2123,7 +2123,7 @@ failed:
> >  	return err;
> >  }
> >
> > -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?)

Don't know.

> >  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

Ok.

> > +		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,
> > +};
> > +
> > +int __init init_rootfs(void)
> > +{
> > +	if (init_inodecache())
> > +		panic("Can't initialize shm inode cache");
>
>                                         "tmpfs inode cache"
>                                      or "shmem inode cache"

Yes, shmem.

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

Thanks for your review!

--
Al

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Greg KH]

On Sun, Jul 30, 2006 at 06:08:14PM +0300, Al Boldi wrote:
> 
> 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.

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

thanks,

greg k-h

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Al Boldi]

Greg KH wrote:
> On Sun, Jul 30, 2006 at 06:08:14PM +0300, Al Boldi wrote:
> > 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.
>
> 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.

It's your call, but this patch should have been in 2.6 since day 1.

Thanks!

--
Al

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[H. Peter Anvin]

Al Boldi wrote:
> 
> 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.

	-hpa

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Al Boldi]

H. Peter Anvin wrote:
> Al Boldi wrote:
> > 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.

Are you sure?

> They're very different from an implementation standpoint.

Think ext2/3.


Thanks!

--
Al

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[H. Peter Anvin]

Al Boldi wrote:
>>>
>>> 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?
> 

Yes.

>> They're very different from an implementation standpoint.
> 
> Think ext2/3.

Not applicable to this case.

	-hpa

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Chris Wright]

* Al Boldi (a1426z@gawab.com) 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.

thanks,
-chris

Re: [stable] [PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs

[Al Boldi]

Chris Wright wrote:
> * Al Boldi (a1426z@gawab.com) 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.

If you mean critical as in "the kernel panics on boot without this patch", 
then yes, this patch is not critical.

But if you think it's important to allow -stable to make full use of rootfs, 
then this patch offers a much needed fix, by simply replugging existing 
code.

Again, it's your call.


Thanks!

--
Al