[PATCH] devtmpfs: support !CONFIG_TMPFS

[PATCH] devtmpfs: support !CONFIG_TMPFS

[Peter Korsgaard]

Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
using ramfs instead.

Saves ~15KB.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 drivers/base/Kconfig    |    2 +-
 drivers/base/devtmpfs.c |    5 +++++
 fs/ramfs/inode.c        |    2 +-
 include/linux/ramfs.h   |    2 ++
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index fd52c48..7e33b16 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -18,7 +18,7 @@ config UEVENT_HELPER_PATH
 
 config DEVTMPFS
 	bool "Maintain a devtmpfs filesystem to mount at /dev"
-	depends on HOTPLUG && SHMEM && TMPFS
+	depends on HOTPLUG
 	help
 	  This creates a tmpfs filesystem instance early at bootup.
 	  In this filesystem, the kernel driver core maintains device
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index dac478c..6927262 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -20,6 +20,7 @@
 #include <linux/namei.h>
 #include <linux/fs.h>
 #include <linux/shmem_fs.h>
+#include <linux/ramfs.h>
 #include <linux/cred.h>
 #include <linux/sched.h>
 #include <linux/init_task.h>
@@ -44,7 +45,11 @@ __setup("devtmpfs.mount=", mount_param);
 static int dev_get_sb(struct file_system_type *fs_type, int flags,
 		      const char *dev_name, void *data, struct vfsmount *mnt)
 {
+#ifdef CONFIG_TMPFS
 	return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
+#else
+	return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
+#endif
 }
 
 static struct file_system_type dev_fs_type = {
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index a6090aa..1a5259a 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -213,7 +213,7 @@ static int ramfs_parse_options(char *data, struct ramfs_mount_opts *opts)
 	return 0;
 }
 
-static int ramfs_fill_super(struct super_block * sb, void * data, int silent)
+int ramfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	struct ramfs_fs_info *fsi;
 	struct inode *inode = NULL;
diff --git a/include/linux/ramfs.h b/include/linux/ramfs.h
index 4e768dd..8600508 100644
--- a/include/linux/ramfs.h
+++ b/include/linux/ramfs.h
@@ -20,4 +20,6 @@ extern const struct file_operations ramfs_file_operations;
 extern const struct vm_operations_struct generic_file_vm_ops;
 extern int __init init_rootfs(void);
 
+int ramfs_fill_super(struct super_block *sb, void *data, int silent);
+
 #endif
-- 
1.7.0

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Michael Tokarev]

Peter Korsgaard wrote:
> Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
> using ramfs instead.
> 
> Saves ~15KB.
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[]> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -44,7 +45,11 @@ __setup("devtmpfs.mount=", mount_param);
>  static int dev_get_sb(struct file_system_type *fs_type, int flags,
>  		      const char *dev_name, void *data, struct vfsmount *mnt)
>  {
> +#ifdef CONFIG_TMPFS
>  	return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
> +#else
> +	return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
> +#endif
>  }

May be completely not to the point or even wrong, but I were
starring at this change for quite some time trying to understand
what's the difference.  Can we do it like this:

#ifdef CONFIG_TMPFS
# define devtmpfs_fill_super shmem_fill_super
#else
# define devtmpfs_fill_super ramfs_fill_super
#endif
  	return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);

?

Or maybe it's just me... ;)

/mjt

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Peter Korsgaard]

>>>>> "Michael" == Michael Tokarev <mjt@tls.msk.ru> writes:

Hi,

 >> +#ifdef CONFIG_TMPFS
 >> return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
 >> +#else
 >> +	return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
 >> +#endif
 >> }

 Michael> May be completely not to the point or even wrong, but I were
 Michael> starring at this change for quite some time trying to understand
 Michael> what's the difference.  Can we do it like this:

 Michael> #ifdef CONFIG_TMPFS
 Michael> # define devtmpfs_fill_super shmem_fill_super
 Michael> #else
 Michael> # define devtmpfs_fill_super ramfs_fill_super
 Michael> #endif
 Michael>   	return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);

 Michael> ?

Sure, if people find that cleaner - Kay?

-- 
Bye, Peter Korsgaard

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Kay Sievers]

On Fri, Mar 12, 2010 at 12:38, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Michael" == Michael Tokarev <mjt@tls.msk.ru> writes:
>  >> +#ifdef CONFIG_TMPFS
>  >> return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
>  >> +#else
>  >> +   return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
>  >> +#endif
>  >> }
>
>  Michael> May be completely not to the point or even wrong, but I were
>  Michael> starring at this change for quite some time trying to understand
>  Michael> what's the difference.  Can we do it like this:
>
>  Michael> #ifdef CONFIG_TMPFS
>  Michael> # define devtmpfs_fill_super shmem_fill_super
>  Michael> #else
>  Michael> # define devtmpfs_fill_super ramfs_fill_super
>  Michael> #endif
>  Michael>       return get_sb_single(fs_type, flags, data, devtmpfs_fill_super, mnt);

> Sure, if people find that cleaner - Kay?

For the style:
  I would prefer your original version.

For the patch:
  Acked-by: Kay Sievers <kay.sievers@vrfy.org>

Thanks,
Kay

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Peter Korsgaard]

>>>>> "Kay" == Kay Sievers <kay.sievers@vrfy.org> writes:

Hi,

 Kay> For the patch:
 Kay>   Acked-by: Kay Sievers <kay.sievers@vrfy.org>

Great - Greg, will you pick this up?

http://patchwork.kernel.org/patch/85237/

-- 
Bye, Peter Korsgaard

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Greg KH]

On Tue, Mar 16, 2010 at 02:04:06PM +0100, Peter Korsgaard wrote:
> >>>>> "Kay" == Kay Sievers <kay.sievers@vrfy.org> writes:
> 
> Hi,
> 
>  Kay> For the patch:
>  Kay>   Acked-by: Kay Sievers <kay.sievers@vrfy.org>
> 
> Great - Greg, will you pick this up?
> 
> http://patchwork.kernel.org/patch/85237/

Yes, it's in my "to-apply" queue.  I'm at a conference for a few days,
so give me a few more :)

thanks,

greg k-h

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Greg KH]

On Fri, Mar 12, 2010 at 11:25:04AM +0100, Peter Korsgaard wrote:
> Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
> using ramfs instead.
> 
> Saves ~15KB.
> 
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
>  drivers/base/Kconfig    |    2 +-
>  drivers/base/devtmpfs.c |    5 +++++
>  fs/ramfs/inode.c        |    2 +-
>  include/linux/ramfs.h   |    2 ++
>  4 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index fd52c48..7e33b16 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -18,7 +18,7 @@ config UEVENT_HELPER_PATH
>  
>  config DEVTMPFS
>  	bool "Maintain a devtmpfs filesystem to mount at /dev"
> -	depends on HOTPLUG && SHMEM && TMPFS
> +	depends on HOTPLUG
>  	help
>  	  This creates a tmpfs filesystem instance early at bootup.
>  	  In this filesystem, the kernel driver core maintains device

With this patch, the Kconfig help text now is incorrect.
Is there a way to explicitly call out in the Kconfig which way devtmpfs
is being created?  How about a multiple selection that chooses either
TMPFS or RAMFS, with the default being TMPFS?

So care to redo this so that people can easily determine what is going
to happen easier than this patch currently causes?

thanks,

greg k-h

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Peter Korsgaard]

>>>>> "Greg" == Greg KH <greg@kroah.com> writes:

Hi,

 >> config DEVTMPFS
 >> bool "Maintain a devtmpfs filesystem to mount at /dev"
 >> -	depends on HOTPLUG && SHMEM && TMPFS
 >> +	depends on HOTPLUG
 >> help
 >> This creates a tmpfs filesystem instance early at bootup.
 >> In this filesystem, the kernel driver core maintains device

 Greg> With this patch, the Kconfig help text now is incorrect.

 Greg> Is there a way to explicitly call out in the Kconfig which way
 Greg> devtmpfs is being created?  How about a multiple selection that
 Greg> chooses either TMPFS or RAMFS, with the default being TMPFS?

I don't think that's needed - If CONFIG_TMPFS isn't set, then ramfs
pretends to be tmpfs anyway, see mm/shmem.c:

static struct file_system_type tmpfs_fs_type = {
	.name		= "tmpfs",
	.get_sb		= ramfs_get_sb,
	.kill_sb	= kill_litter_super,
};

So calling it tmpfs isn't really wrong.

 Greg> So care to redo this so that people can easily determine what is going
 Greg> to happen easier than this patch currently causes?

We can change the help text to say tmpfs/ramfs if you prefer - OK?

-- 
Bye, Peter Korsgaard

Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

[Greg KH]

On Tue, Mar 16, 2010 at 08:14:05PM +0100, Peter Korsgaard wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
> 
> Hi,
> 
>  >> config DEVTMPFS
>  >> bool "Maintain a devtmpfs filesystem to mount at /dev"
>  >> -	depends on HOTPLUG && SHMEM && TMPFS
>  >> +	depends on HOTPLUG
>  >> help
>  >> This creates a tmpfs filesystem instance early at bootup.
>  >> In this filesystem, the kernel driver core maintains device
> 
>  Greg> With this patch, the Kconfig help text now is incorrect.
> 
>  Greg> Is there a way to explicitly call out in the Kconfig which way
>  Greg> devtmpfs is being created?  How about a multiple selection that
>  Greg> chooses either TMPFS or RAMFS, with the default being TMPFS?
> 
> I don't think that's needed - If CONFIG_TMPFS isn't set, then ramfs
> pretends to be tmpfs anyway, see mm/shmem.c:
> 
> static struct file_system_type tmpfs_fs_type = {
> 	.name		= "tmpfs",
> 	.get_sb		= ramfs_get_sb,
> 	.kill_sb	= kill_litter_super,
> };
> 
> So calling it tmpfs isn't really wrong.

Heh, wow, I didn't realize that.

>  Greg> So care to redo this so that people can easily determine what is going
>  Greg> to happen easier than this patch currently causes?
> 
> We can change the help text to say tmpfs/ramfs if you prefer - OK?

Yes, maybe with an explaination that if TMPFS is not set, ramfs will be
used.

thanks,

greg k-h

[PATCH-V2] devtmpfs: support !CONFIG_TMPFS

[Peter Korsgaard]

Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
using ramfs instead.

Saves ~15KB.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Kay Sievers <kay.sievers@vrfy.org>
---
Changes since v1:
 - Added Kay's ack
 - Added comment about it using ramfs if CONFIG_TMPFS isn't enabled as
   requested by Greg

 drivers/base/Kconfig    |    7 +++++--
 drivers/base/devtmpfs.c |    5 +++++
 fs/ramfs/inode.c        |    2 +-
 include/linux/ramfs.h   |    2 ++
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index fd52c48..ef38aff 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -18,9 +18,9 @@ config UEVENT_HELPER_PATH
 
 config DEVTMPFS
 	bool "Maintain a devtmpfs filesystem to mount at /dev"
-	depends on HOTPLUG && SHMEM && TMPFS
+	depends on HOTPLUG
 	help
-	  This creates a tmpfs filesystem instance early at bootup.
+	  This creates a tmpfs/ramfs filesystem instance early at bootup.
 	  In this filesystem, the kernel driver core maintains device
 	  nodes with their default names and permissions for all
 	  registered devices with an assigned major/minor number.
@@ -33,6 +33,9 @@ config DEVTMPFS
 	  functional /dev without any further help. It also allows simple
 	  rescue systems, and reliably handles dynamic major/minor numbers.
 
+	  Notice: if CONFIG_TMPFS isn't enabled, the simpler ramfs
+	  file system will be used instead.
+
 config DEVTMPFS_MOUNT
 	bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
 	depends on DEVTMPFS
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index dac478c..6927262 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -20,6 +20,7 @@
 #include <linux/namei.h>
 #include <linux/fs.h>
 #include <linux/shmem_fs.h>
+#include <linux/ramfs.h>
 #include <linux/cred.h>
 #include <linux/sched.h>
 #include <linux/init_task.h>
@@ -44,7 +45,11 @@ __setup("devtmpfs.mount=", mount_param);
 static int dev_get_sb(struct file_system_type *fs_type, int flags,
 		      const char *dev_name, void *data, struct vfsmount *mnt)
 {
+#ifdef CONFIG_TMPFS
 	return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
+#else
+	return get_sb_single(fs_type, flags, data, ramfs_fill_super, mnt);
+#endif
 }
 
 static struct file_system_type dev_fs_type = {
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index a6090aa..1a5259a 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -213,7 +213,7 @@ static int ramfs_parse_options(char *data, struct ramfs_mount_opts *opts)
 	return 0;
 }
 
-static int ramfs_fill_super(struct super_block * sb, void * data, int silent)
+int ramfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	struct ramfs_fs_info *fsi;
 	struct inode *inode = NULL;
diff --git a/include/linux/ramfs.h b/include/linux/ramfs.h
index 4e768dd..8600508 100644
--- a/include/linux/ramfs.h
+++ b/include/linux/ramfs.h
@@ -20,4 +20,6 @@ extern const struct file_operations ramfs_file_operations;
 extern const struct vm_operations_struct generic_file_vm_ops;
 extern int __init init_rootfs(void);
 
+int ramfs_fill_super(struct super_block *sb, void *data, int silent);
+
 #endif
-- 
1.7.0