[PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
It's been tested and agreed by three major distros that this is a good
idea.  SuSE has been shipping this in their kernels for a while now with
no problems, and actual speedups measured on their boot times.  Gentoo
also has been testing it, but we haven't gotten a tested-by: line from
them yet, hopefully that will happen soon.

A number of embedded distros have also privately said they would be
using this patch, I really don't understand why they don't publically
want to state this, but oh well...

It's been in linux-next for many months now, with no reported
regressions at all as well.

thanks,

greg k-h

--------------


From: Kay Sievers <kay.sievers@vrfy.org>

Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will provide a
device node in devtmpfs.

Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs.
Unmodified udev versions will run just fine on top of it, and will
recognize an already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy still
needs to be applied by userspace.

If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will no longer be removed by devtmpfs.

If it is requested to auto-mount it, it makes init=/bin/sh work
without any further userspace support. /dev will be fully populated
and dynamic, and always reflect the current device state of the kernel.
With the commonly used dynamic device numbers, it solves the problem
where static devices nodes may point to the wrong devices.

It is intended to make the initial bootup logic simpler and more robust,
by de-coupling the creation of the inital environment, to reliably run
userspace processes, from a complex userspace bootstrap logic to provide
a working /dev.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Tested-By: Harald Hoyer <harald@redhat.com>
Tested-By: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/Kconfig     |   25 +++
 drivers/base/Makefile    |    1 
 drivers/base/base.h      |    6 
 drivers/base/core.c      |    3 
 drivers/base/devtmpfs.c  |  367 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/base/init.c      |    1 
 include/linux/device.h   |   10 +
 include/linux/shmem_fs.h |    3 
 init/do_mounts.c         |    2 
 init/main.c              |    2 
 mm/shmem.c               |    9 -
 11 files changed, 422 insertions(+), 7 deletions(-)

--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -139,3 +139,9 @@ static inline void module_add_driver(str
 				     struct device_driver *drv) { }
 static inline void module_remove_driver(struct device_driver *drv) { }
 #endif
+
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_init(void);
+#else
+static inline int devtmpfs_init(void) { return 0; }
+#endif
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -929,6 +929,8 @@ int device_add(struct device *dev)
 		error = device_create_sys_dev_entry(dev);
 		if (error)
 			goto devtattrError;
+
+		devtmpfs_create_node(dev);
 	}
 
 	error = device_add_class_symlinks(dev);
@@ -1075,6 +1077,7 @@ void device_del(struct device *dev)
 	if (parent)
 		klist_del(&dev->p->knode_parent);
 	if (MAJOR(dev->devt)) {
+		devtmpfs_delete_node(dev);
 		device_remove_sys_dev_entry(dev);
 		device_remove_file(dev, &devt_attr);
 	}
--- /dev/null
+++ b/drivers/base/devtmpfs.c
@@ -0,0 +1,367 @@
+/*
+ * devtmpfs - kernel-maintained tmpfs-based /dev
+ *
+ * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
+ *
+ * During bootup, before any driver core device is registered,
+ * devtmpfs, a tmpfs-based filesystem is created. Every driver-core
+ * device which requests a device node, will add a node in this
+ * filesystem. The node is named after the the name of the device,
+ * or the susbsytem can provide a custom name. All devices are
+ * owned by root and have a mode of 0600.
+ */
+
+#include <linux/kernel.h>
+#include <linux/syscalls.h>
+#include <linux/mount.h>
+#include <linux/device.h>
+#include <linux/genhd.h>
+#include <linux/namei.h>
+#include <linux/fs.h>
+#include <linux/shmem_fs.h>
+#include <linux/cred.h>
+#include <linux/init_task.h>
+
+static struct vfsmount *dev_mnt;
+
+#if defined CONFIG_DEVTMPFS_MOUNT
+static int dev_mount = 1;
+#else
+static int dev_mount;
+#endif
+
+static int __init mount_param(char *str)
+{
+	dev_mount = simple_strtoul(str, NULL, 0);
+	return 1;
+}
+__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)
+{
+	return get_sb_single(fs_type, flags, data, shmem_fill_super, mnt);
+}
+
+static struct file_system_type dev_fs_type = {
+	.name = "devtmpfs",
+	.get_sb = dev_get_sb,
+	.kill_sb = kill_litter_super,
+};
+
+#ifdef CONFIG_BLOCK
+static inline int is_blockdev(struct device *dev)
+{
+	return dev->class == &block_class;
+}
+#else
+static inline int is_blockdev(struct device *dev) { return 0; }
+#endif
+
+static int dev_mkdir(const char *name, mode_t mode)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	dentry = lookup_create(&nd, 1);
+	if (!IS_ERR(dentry)) {
+		err = vfs_mkdir(nd.path.dentry->d_inode, dentry, mode);
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int create_path(const char *nodepath)
+{
+	char *path;
+	struct nameidata nd;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      path, LOOKUP_PARENT, &nd);
+	if (err == 0) {
+		struct dentry *dentry;
+
+		/* create directory right away */
+		dentry = lookup_create(&nd, 1);
+		if (!IS_ERR(dentry)) {
+			err = vfs_mkdir(nd.path.dentry->d_inode,
+					dentry, 0775);
+			dput(dentry);
+		}
+		mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+		path_put(&nd.path);
+	} else if (err == -ENOENT) {
+		char *s;
+
+		/* parent directories do not exist, create them */
+		s = path;
+		while (1) {
+			s = strchr(s, '/');
+			if (!s)
+				break;
+			s[0] = '\0';
+			err = dev_mkdir(path, 0755);
+			if (err && err != -EEXIST)
+				break;
+			s[0] = '/';
+			s++;
+		}
+	}
+
+	kfree(path);
+	return err;
+}
+
+int devtmpfs_create_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	const struct cred *curr_cred;
+	mode_t mode;
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	if (is_blockdev(dev))
+		mode = S_IFBLK|0600;
+	else
+		mode = S_IFCHR|0600;
+
+	curr_cred = override_creds(&init_cred);
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err == -ENOENT) {
+		/* create missing parent directories */
+		create_path(nodename);
+		err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+				      nodename, LOOKUP_PARENT, &nd);
+		if (err)
+			goto out;
+	}
+
+	dentry = lookup_create(&nd, 0);
+	if (!IS_ERR(dentry)) {
+		err = vfs_mknod(nd.path.dentry->d_inode,
+				dentry, mode, dev->devt);
+		/* mark as kernel created inode */
+		if (!err)
+			dentry->d_inode->i_private = &dev_mnt;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+out:
+	kfree(tmp);
+	revert_creds(curr_cred);
+	return err;
+}
+
+static int dev_rmdir(const char *name)
+{
+	struct nameidata nd;
+	struct dentry *dentry;
+	int err;
+
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      name, LOOKUP_PARENT, &nd);
+	if (err)
+		return err;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode)
+			err = vfs_rmdir(nd.path.dentry->d_inode, dentry);
+		else
+			err = -ENOENT;
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	return err;
+}
+
+static int delete_path(const char *nodepath)
+{
+	const char *path;
+	int err = 0;
+
+	path = kstrdup(nodepath, GFP_KERNEL);
+	if (!path)
+		return -ENOMEM;
+
+	while (1) {
+		char *base;
+
+		base = strrchr(path, '/');
+		if (!base)
+			break;
+		base[0] = '\0';
+		err = dev_rmdir(path);
+		if (err)
+			break;
+	}
+
+	kfree(path);
+	return err;
+}
+
+static int dev_mynode(struct device *dev, struct inode *inode, struct kstat *stat)
+{
+	/* did we create it */
+	if (inode->i_private != &dev_mnt)
+		return 0;
+
+	/* does the dev_t match */
+	if (is_blockdev(dev)) {
+		if (!S_ISBLK(stat->mode))
+			return 0;
+	} else {
+		if (!S_ISCHR(stat->mode))
+			return 0;
+	}
+	if (stat->rdev != dev->devt)
+		return 0;
+
+	/* ours */
+	return 1;
+}
+
+int devtmpfs_delete_node(struct device *dev)
+{
+	const char *tmp = NULL;
+	const char *nodename;
+	const struct cred *curr_cred;
+	struct nameidata nd;
+	struct dentry *dentry;
+	struct kstat stat;
+	int deleted = 1;
+	int err;
+
+	if (!dev_mnt)
+		return 0;
+
+	nodename = device_get_nodename(dev, &tmp);
+	if (!nodename)
+		return -ENOMEM;
+
+	curr_cred = override_creds(&init_cred);
+	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
+			      nodename, LOOKUP_PARENT, &nd);
+	if (err)
+		goto out;
+
+	mutex_lock_nested(&nd.path.dentry->d_inode->i_mutex, I_MUTEX_PARENT);
+	dentry = lookup_one_len(nd.last.name, nd.path.dentry, nd.last.len);
+	if (!IS_ERR(dentry)) {
+		if (dentry->d_inode) {
+			err = vfs_getattr(nd.path.mnt, dentry, &stat);
+			if (!err && dev_mynode(dev, dentry->d_inode, &stat)) {
+				err = vfs_unlink(nd.path.dentry->d_inode,
+						 dentry);
+				if (!err || err == -ENOENT)
+					deleted = 1;
+			}
+		} else {
+			err = -ENOENT;
+		}
+		dput(dentry);
+	} else {
+		err = PTR_ERR(dentry);
+	}
+	mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
+
+	path_put(&nd.path);
+	if (deleted && strchr(nodename, '/'))
+		delete_path(nodename);
+out:
+	kfree(tmp);
+	revert_creds(curr_cred);
+	return err;
+}
+
+/*
+ * If configured, or requested by the commandline, devtmpfs will be
+ * auto-mounted after the kernel mounted the root filesystem.
+ */
+int devtmpfs_mount(const char *mountpoint)
+{
+	struct path path;
+	int err;
+
+	if (!dev_mount)
+		return 0;
+
+	if (!dev_mnt)
+		return 0;
+
+	err = kern_path(mountpoint, LOOKUP_FOLLOW, &path);
+	if (err)
+		return err;
+	err = do_add_mount(dev_mnt, &path, 0, NULL);
+	if (err)
+		printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
+	else
+		printk(KERN_INFO "devtmpfs: mounted\n");
+	path_put(&path);
+	return err;
+}
+
+/*
+ * Create devtmpfs instance, driver-core devices will add their device
+ * nodes here.
+ */
+int __init devtmpfs_init(void)
+{
+	int err;
+	struct vfsmount *mnt;
+
+	err = register_filesystem(&dev_fs_type);
+	if (err) {
+		printk(KERN_ERR "devtmpfs: unable to register devtmpfs "
+		       "type %i\n", err);
+		return err;
+	}
+
+	mnt = kern_mount(&dev_fs_type);
+	if (IS_ERR(mnt)) {
+		err = PTR_ERR(mnt);
+		printk(KERN_ERR "devtmpfs: unable to create devtmpfs %i\n", err);
+		unregister_filesystem(&dev_fs_type);
+		return err;
+	}
+	dev_mnt = mnt;
+
+	printk(KERN_INFO "devtmpfs: initialized\n");
+	return 0;
+}
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -20,6 +20,7 @@
 void __init driver_init(void)
 {
 	/* These are the core pieces */
+	devtmpfs_init();
 	devices_init();
 	buses_init();
 	classes_init();
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -8,6 +8,31 @@ config UEVENT_HELPER_PATH
 	  Path to uevent helper program forked by the kernel for
 	  every uevent.
 
+config DEVTMPFS
+	bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
+	depends on HOTPLUG && SHMEM && TMPFS
+	help
+	  This creates a tmpfs filesystem, and mounts it at bootup
+	  and mounts it at /dev. The kernel driver core creates device
+	  nodes for all registered devices in that filesystem. All device
+	  nodes are owned by root and have the default mode of 0600.
+	  Userspace can add and delete the nodes as needed. This is
+	  intended to simplify bootup, and make it possible to delay
+	  the initial coldplug at bootup done by udev in userspace.
+	  It should also provide a simpler way for rescue systems
+	  to bring up a kernel with dynamic major/minor numbers.
+	  Meaningful symlinks, permissions and device ownership must
+	  still be handled by userspace.
+	  If unsure, say N here.
+
+config DEVTMPFS_MOUNT
+	bool "Automount devtmpfs at /dev"
+	depends on DEVTMPFS
+	help
+	  This will mount devtmpfs at /dev if the kernel mounts the root
+	  filesystem. It will not affect initramfs based mounting.
+	  If unsure, say N here.
+
 config STANDALONE
 	bool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTAL
 	default y
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,6 +4,7 @@ obj-y			:= core.o sys.o bus.o dd.o \
 			   driver.o class.o platform.o \
 			   cpu.o firmware.o init.o map.o devres.o \
 			   attribute_container.o transport_class.o
+obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-y			+= power/
 obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -543,6 +543,16 @@ extern void put_device(struct device *de
 
 extern void wait_for_device_probe(void);
 
+#ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_create_node(struct device *dev);
+extern int devtmpfs_delete_node(struct device *dev);
+extern int devtmpfs_mount(const char *mountpoint);
+#else
+static inline int devtmpfs_create_node(struct device *dev) { return 0; }
+static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
+static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
+#endif
+
 /* drivers/base/power/shutdown.c */
 extern void device_shutdown(void);
 
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -38,6 +38,9 @@ static inline struct shmem_inode_info *S
 	return container_of(inode, struct shmem_inode_info, vfs_inode);
 }
 
+extern int init_tmpfs(void);
+extern int shmem_fill_super(struct super_block *sb, void *data, int silent);
+
 #ifdef CONFIG_TMPFS_POSIX_ACL
 int shmem_permission(struct inode *, int);
 int shmem_acl_init(struct inode *, struct inode *);
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -415,7 +415,7 @@ void __init prepare_namespace(void)
 
 	mount_root();
 out:
+	devtmpfs_mount("dev");
 	sys_mount(".", "/", NULL, MS_MOVE, NULL);
 	sys_chroot(".");
 }
-
--- a/init/main.c
+++ b/init/main.c
@@ -68,6 +68,7 @@
 #include <linux/async.h>
 #include <linux/kmemcheck.h>
 #include <linux/kmemtrace.h>
+#include <linux/shmem_fs.h>
 #include <trace/boot.h>
 
 #include <asm/io.h>
@@ -808,6 +809,7 @@ static void __init do_basic_setup(void)
 	init_workqueues();
 	cpuset_init_smp();
 	usermodehelper_init();
+	init_tmpfs();
 	driver_init();
 	init_irq_proc();
 	do_ctors();
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2298,8 +2298,7 @@ static void shmem_put_super(struct super
 	sb->s_fs_info = NULL;
 }
 
-static int shmem_fill_super(struct super_block *sb,
-			    void *data, int silent)
+int shmem_fill_super(struct super_block *sb, void *data, int silent)
 {
 	struct inode *inode;
 	struct dentry *root;
@@ -2519,7 +2518,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	int error;
 
@@ -2576,7 +2575,7 @@ static struct file_system_type tmpfs_fs_
 	.kill_sb	= kill_litter_super,
 };
 
-static int __init init_tmpfs(void)
+int __init init_tmpfs(void)
 {
 	BUG_ON(register_filesystem(&tmpfs_fs_type) != 0);
 
@@ -2687,5 +2686,3 @@ int shmem_zero_setup(struct vm_area_stru
 	vma->vm_ops = &shmem_vm_ops;
 	return 0;
 }
-
-module_init(init_tmpfs)

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Vrabel]

Greg KH wrote:
> 
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -929,6 +929,8 @@ int device_add(struct device *dev)
>  		error = device_create_sys_dev_entry(dev);
>  		if (error)
>  			goto devtattrError;
> +
> +		devtmpfs_create_node(dev);
>  	}
>  
>  	error = device_add_class_symlinks(dev);
[...]
> --- /dev/null
> +++ b/drivers/base/devtmpfs.c
[...]
> +int devtmpfs_create_node(struct device *dev)

Returns an int that's never checked.  Is this intentional?

> +int devtmpfs_delete_node(struct device *dev)

Similarly.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 05, 2009 at 06:43:02PM +0100, David Vrabel wrote:
> Greg KH wrote:
> > 
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -929,6 +929,8 @@ int device_add(struct device *dev)
> >  		error = device_create_sys_dev_entry(dev);
> >  		if (error)
> >  			goto devtattrError;
> > +
> > +		devtmpfs_create_node(dev);
> >  	}
> >  
> >  	error = device_add_class_symlinks(dev);
> [...]
> > --- /dev/null
> > +++ b/drivers/base/devtmpfs.c
> [...]
> > +int devtmpfs_create_node(struct device *dev)
> 
> Returns an int that's never checked.  Is this intentional?
> 
> > +int devtmpfs_delete_node(struct device *dev)
> 
> Similarly.

Probably not, Kay, care to respin this?

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Alan Cox]

On Wed, 5 Aug 2009 10:15:13 -0700
Greg KH <greg@kroah.com> wrote:

> Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.

You seem to have reposted it rather than anyone addressing any of the
complaints people made about ?

To quote Christoph

> What tree did you find with devtmpfs in it?  It was pretty clearly
> rejected when it came up.

and Arjan (who is doing about the fastest Linux boot anyone has and has
better data than anyone else)

> so just to state the obvious: this code is not needed to boot fast.
> It is mostly a workaround for having a bad initrd; if you don't use an
> initrd, or if you use an initrd that's made with the right device nodes
> in it already, you really just don't need this.

> I would much rather that you just fix your initrd... than to put this
> sort of thing into the kernel....

plus 

> Eric has shown that just making the nodes is 0.06 seconds with todays
> sysfs interface, and there is room for improvement,

and Erik Biederman

>> option for us. And still, nobody will be forced
>> to use it, it's entirely optional. For our systems, we decided to do
>> it that way, and we ship it already in the distro, and if there are no
>> substantial problems coming up, which we don't expect, we will
>> continue using it.  

> Yes but you are asking all of us to maintain it.  Forever in perpetuity.
> A better case needs to be made than you have already shipped the code.

Also can you confirm the SELinux issues raised by Stephen Smalley and
David Quigley were fixed and resolved.

Alan

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 05, 2009 at 07:20:37PM +0100, Alan Cox wrote:
> On Wed, 5 Aug 2009 10:15:13 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> 
> You seem to have reposted it rather than anyone addressing any of the
> complaints people made about ?
> 
> To quote Christoph
> 
> > What tree did you find with devtmpfs in it?  It was pretty clearly
> > rejected when it came up.

That's not anything to address, what do you want me to say, "maple"?  :)

> and Arjan (who is doing about the fastest Linux boot anyone has and has
> better data than anyone else)

We did this work based on Arjan's work.  It solves a problem that Moblin
has as well, which is why Novell is using it for their Moblin-based
images they are shipping.  It makes things go faster, with a simpler
userspace codepath, and we have the numbers as have been previously
posted.

> > so just to state the obvious: this code is not needed to boot fast.
> > It is mostly a workaround for having a bad initrd; if you don't use an
> > initrd, or if you use an initrd that's made with the right device nodes
> > in it already, you really just don't need this.
> 
> > I would much rather that you just fix your initrd... than to put this
> > sort of thing into the kernel....

We have "fixed" our initrd, so much so we don't even use one for Moblin,
just like Intel doesn't.  The userspace boot sequence uses this for a
faster boot time.  Ubuntu and Red Hat both independently confirmed this
as well.

> plus 
> 
> > Eric has shown that just making the nodes is 0.06 seconds with todays
> > sysfs interface, and there is room for improvement,

A 0.06 speedup is still a speedup, right?  :)

Seriously, we saw much more than that, about 0.5 from what I last
remember, Kay?

> and Erik Biederman
> 
> >> option for us. And still, nobody will be forced
> >> to use it, it's entirely optional. For our systems, we decided to do
> >> it that way, and we ship it already in the distro, and if there are no
> >> substantial problems coming up, which we don't expect, we will
> >> continue using it.  
> 
> > Yes but you are asking all of us to maintain it.  Forever in perpetuity.
> > A better case needs to be made than you have already shipped the code.

I will maintain it.  Or Kay will.  It's the equalivant of adding a
driver to the kernel, if you don't want it, it touches nothing else.
The diffstat shows a bit of reorg to handle this, I can split it into 2
patches if that's really necessary.

> Also can you confirm the SELinux issues raised by Stephen Smalley and
> David Quigley were fixed and resolved.

>From what I recall, yes, they were.  I'm guessing the Red Hat boot tests
performed by Harald confirms this.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 05, 2009 at 11:28:05AM -0700, Greg KH wrote:
> On Wed, Aug 05, 2009 at 07:20:37PM +0100, Alan Cox wrote:
> > On Wed, 5 Aug 2009 10:15:13 -0700
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> > 
> > You seem to have reposted it rather than anyone addressing any of the
> > complaints people made about ?
> > 
> > To quote Christoph
> > 
> > > What tree did you find with devtmpfs in it?  It was pretty clearly
> > > rejected when it came up.
> 
> That's not anything to address, what do you want me to say, "maple"?  :)
> 
> > and Arjan (who is doing about the fastest Linux boot anyone has and has
> > better data than anyone else)
> 
> We did this work based on Arjan's work.  It solves a problem that Moblin
> has as well, which is why Novell is using it for their Moblin-based
> images they are shipping.  It makes things go faster, with a simpler
> userspace codepath, and we have the numbers as have been previously
> posted.

And to expound on this a bit, it's not just about fast boot, although
this is a great benefit of this patch.

It makes the userspace boot process much simpler and easier to maintain,
as well as providing a way to handle rescue disks and images trivially,
and it makes the kernel _less_ dependant on the early userspace bootup
scripts.

And then there's the great reason Kay previously stated, "if sysfs has
all the names, numbers, and device properties, why would we need complex
userspace to have the nodes?"

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Alan Jenkins]

On 8/5/09, Greg KH <greg@kroah.com> wrote:
> Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> It's been tested and agreed by three major distros that this is a good
> idea.  SuSE has been shipping this in their kernels for a while now with
> no problems, and actual speedups measured on their boot times.  Gentoo
> also has been testing it, but we haven't gotten a tested-by: line from
> them yet, hopefully that will happen soon.
>
> A number of embedded distros have also privately said they would be
> using this patch, I really don't understand why they don't publically
> want to state this, but oh well...
>
> It's been in linux-next for many months now, with no reported
> regressions at all as well.
>
> thanks,
>
> greg k-h
>
> --------------
>
>
> From: Kay Sievers <kay.sievers@vrfy.org>
>
> Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
> very early at kernel initialization, before any driver-core device
> is registered. Every device with a major/minor will provide a
> device node in devtmpfs.
>
> Devtmpfs can be changed and altered by userspace at any time,
> and in any way needed - just like today's udev-mounted tmpfs.
> Unmodified udev versions will run just fine on top of it, and will
> recognize an already existing kernel-created device node and use it.
> The default node permissions are root:root 0600. Proper permissions
> and user/group ownership, meaningful symlinks, all other policy still
> needs to be applied by userspace.

> +	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
> +			      path, LOOKUP_PARENT, &nd);
> +	if (err == 0) {
> +		struct dentry *dentry;
> +
> +		/* create directory right away */
> +		dentry = lookup_create(&nd, 1);
> +		if (!IS_ERR(dentry)) {
> +			err = vfs_mkdir(nd.path.dentry->d_inode,
> +					dentry, 0775);

Is there a typo here?  I think the mode should be 0755.   0755 is used
below, and that does fit better with the 0600 mode for device nodes.

Thanks
Alan

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 05, 2009 at 09:55:49PM +0100, Alan Jenkins wrote:
> On 8/5/09, Greg KH <greg@kroah.com> wrote:
> > Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> > It's been tested and agreed by three major distros that this is a good
> > idea.  SuSE has been shipping this in their kernels for a while now with
> > no problems, and actual speedups measured on their boot times.  Gentoo
> > also has been testing it, but we haven't gotten a tested-by: line from
> > them yet, hopefully that will happen soon.
> >
> > A number of embedded distros have also privately said they would be
> > using this patch, I really don't understand why they don't publically
> > want to state this, but oh well...
> >
> > It's been in linux-next for many months now, with no reported
> > regressions at all as well.
> >
> > thanks,
> >
> > greg k-h
> >
> > --------------
> >
> >
> > From: Kay Sievers <kay.sievers@vrfy.org>
> >
> > Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
> > very early at kernel initialization, before any driver-core device
> > is registered. Every device with a major/minor will provide a
> > device node in devtmpfs.
> >
> > Devtmpfs can be changed and altered by userspace at any time,
> > and in any way needed - just like today's udev-mounted tmpfs.
> > Unmodified udev versions will run just fine on top of it, and will
> > recognize an already existing kernel-created device node and use it.
> > The default node permissions are root:root 0600. Proper permissions
> > and user/group ownership, meaningful symlinks, all other policy still
> > needs to be applied by userspace.
> 
> > +	err = vfs_path_lookup(dev_mnt->mnt_root, dev_mnt,
> > +			      path, LOOKUP_PARENT, &nd);
> > +	if (err == 0) {
> > +		struct dentry *dentry;
> > +
> > +		/* create directory right away */
> > +		dentry = lookup_create(&nd, 1);
> > +		if (!IS_ERR(dentry)) {
> > +			err = vfs_mkdir(nd.path.dentry->d_inode,
> > +					dentry, 0775);
> 
> Is there a typo here?  I think the mode should be 0755.   0755 is used
> below, and that does fit better with the 0600 mode for device nodes.

Yeah, I think you are correct.  Kay, any objection to me making this
change?

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Kay Sievers]

On Thu, Aug 6, 2009 at 02:06, Greg KH<greg@kroah.com> wrote:
> On Wed, Aug 05, 2009 at 09:55:49PM +0100, Alan Jenkins wrote:

>> > +                   err = vfs_mkdir(nd.path.dentry->d_inode,
>> > +                                   dentry, 0775);
>>
>> Is there a typo here?  I think the mode should be 0755.   0755 is used
>> below, and that does fit better with the 0600 mode for device nodes.
>
> Yeah, I think you are correct.  Kay, any objection to me making this
> change?

No, sure no objection. It sounds right to use 0755.
I was just waiting if more things to fix come up. :)

Thanks,
Kay

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Andi Kleen]

Greg KH <greg@kroah.com> writes:
>
> It makes the userspace boot process much simpler and easier to maintain,
> as well as providing a way to handle rescue disks and images trivially,
> and it makes the kernel _less_ dependant on the early userspace bootup
> scripts.

As a initrd less kernel user I can really only agree: getting rid
of the udev-in-initrd requirement would be a big step forward
in usability. Typically I always have to pre populate 
a on disk /dev manually first to get my kernels to boot.

> And then there's the great reason Kay previously stated, "if sysfs has
> all the names, numbers, and device properties, why would we need complex
> userspace to have the nodes?"

Exactly.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Thu, 2009-08-06 at 17:46 +0200, Andi Kleen wrote:
> Greg KH <greg@kroah.com> writes:
> >
> > It makes the userspace boot process much simpler and easier to maintain,
> > as well as providing a way to handle rescue disks and images trivially,
> > and it makes the kernel _less_ dependant on the early userspace bootup
> > scripts.
> 
> As a initrd less kernel user I can really only agree: getting rid
> of the udev-in-initrd requirement would be a big step forward
> in usability. Typically I always have to pre populate 
> a on disk /dev manually first to get my kernels to boot.

If you use mount by label or UUID, you still need udev (or other tools)
in the initrd to find the right disk, correct? And for distros that want
to support that, does this really reduce the amount of code in the
initrd?

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Andi Kleen wrote:
> Greg KH <greg@kroah.com> writes:
> > It makes the userspace boot process much simpler and easier to maintain,
> > as well as providing a way to handle rescue disks and images trivially,
> > and it makes the kernel _less_ dependant on the early userspace bootup
> > scripts.
>
> As a initrd less kernel user I can really only agree: getting rid
> of the udev-in-initrd requirement would be a big step forward
> in usability. Typically I always have to pre populate
> a on disk /dev manually first to get my kernels to boot.

Oh good, I thought I was the only one doing that.

The reason I don't like udev is that it's just to slow; something like a 5-10s 
delay on each boot.  No idea why it should be so slow, but it's probably 
probing the kernel for all available devices at boot, when it could be much 
quicker by probing for the device on access.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Andi Kleen]

> If you use mount by label or UUID, you still need udev (or other tools)

I don't use that on my boxes.

> in the initrd to find the right disk, correct? And for distros that want
> to support that, does this really reduce the amount of code in the
> initrd?

There are more users than just distros.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Kay Sievers]

On Thu, Aug 6, 2009 at 19:06, Al Boldi<a1426z@gawab.com> wrote:
> Andi Kleen wrote:
>> Greg KH <greg@kroah.com> writes:
>> > It makes the userspace boot process much simpler and easier to maintain,
>> > as well as providing a way to handle rescue disks and images trivially,
>> > and it makes the kernel _less_ dependant on the early userspace bootup
>> > scripts.
>>
>> As a initrd less kernel user I can really only agree: getting rid
>> of the udev-in-initrd requirement would be a big step forward
>> in usability. Typically I always have to pre populate
>> a on disk /dev manually first to get my kernels to boot.
>
> Oh good, I thought I was the only one doing that.
>
> The reason I don't like udev is that it's just to slow; something like a 5-10s
> delay on each boot.  No idea why it should be so slow,

Because you setup is broken, I guess.

> but it's probably
> probing the kernel for all available devices at boot, when it could be much
> quicker by probing for the device on access.

It takes more like 0.5 - 0.7 seconds on a usual setup.

Kay

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Kay Sievers wrote:
> On Thu, Aug 6, 2009 at 19:06, Al Boldi<a1426z@gawab.com> wrote:
> > Andi Kleen wrote:
> >> Greg KH <greg@kroah.com> writes:
> >> > It makes the userspace boot process much simpler and easier to
> >> > maintain, as well as providing a way to handle rescue disks and images
> >> > trivially, and it makes the kernel _less_ dependant on the early
> >> > userspace bootup scripts.
> >>
> >> As a initrd less kernel user I can really only agree: getting rid
> >> of the udev-in-initrd requirement would be a big step forward
> >> in usability. Typically I always have to pre populate
> >> a on disk /dev manually first to get my kernels to boot.
> >
> > Oh good, I thought I was the only one doing that.
> >
> > The reason I don't like udev is that it's just to slow; something like a
> > 5-10s delay on each boot.  No idea why it should be so slow,
>
> Because you setup is broken, I guess.
>
> > but it's probably
> > probing the kernel for all available devices at boot, when it could be
> > much quicker by probing for the device on access.
>
> It takes more like 0.5 - 0.7 seconds on a usual setup.

I don't know about your setup, but all dists I used (fedora, mandriva, ubuntu, 
debian) hang every boot for 5-10s.

Are you saying devtmpfs has the same delay as udev?

Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Kay Sievers]

On Thu, Aug 6, 2009 at 19:27, Al Boldi<a1426z@gawab.com> wrote:
> Kay Sievers wrote:
>> On Thu, Aug 6, 2009 at 19:06, Al Boldi<a1426z@gawab.com> wrote:
>> > Andi Kleen wrote:
>> >> Greg KH <greg@kroah.com> writes:
>> >> > It makes the userspace boot process much simpler and easier to
>> >> > maintain, as well as providing a way to handle rescue disks and images
>> >> > trivially, and it makes the kernel _less_ dependant on the early
>> >> > userspace bootup scripts.
>> >>
>> >> As a initrd less kernel user I can really only agree: getting rid
>> >> of the udev-in-initrd requirement would be a big step forward
>> >> in usability. Typically I always have to pre populate
>> >> a on disk /dev manually first to get my kernels to boot.
>> >
>> > Oh good, I thought I was the only one doing that.
>> >
>> > The reason I don't like udev is that it's just to slow; something like a
>> > 5-10s delay on each boot.  No idea why it should be so slow,
>>
>> Because you setup is broken, I guess.
>>
>> > but it's probably
>> > probing the kernel for all available devices at boot, when it could be
>> > much quicker by probing for the device on access.
>>
>> It takes more like 0.5 - 0.7 seconds on a usual setup.
>
> I don't know about your setup, but all dists I used (fedora, mandriva, ubuntu,
> debian) hang every boot for 5-10s.

That's just not true. If you want to solve your issue, which has
nothing to do with devtmpfs, please move that to the
linux-hotplug@vger.kernel.org list.

Thanks,
Kay

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Thu, Aug 06, 2009 at 12:20:58PM -0400, David Dillow wrote:
> On Thu, 2009-08-06 at 17:46 +0200, Andi Kleen wrote:
> > Greg KH <greg@kroah.com> writes:
> > >
> > > It makes the userspace boot process much simpler and easier to maintain,
> > > as well as providing a way to handle rescue disks and images trivially,
> > > and it makes the kernel _less_ dependant on the early userspace bootup
> > > scripts.
> > 
> > As a initrd less kernel user I can really only agree: getting rid
> > of the udev-in-initrd requirement would be a big step forward
> > in usability. Typically I always have to pre populate 
> > a on disk /dev manually first to get my kernels to boot.
> 
> If you use mount by label or UUID, you still need udev (or other tools)
> in the initrd to find the right disk, correct?

Yes, you would.

> And for distros that want to support that, does this really reduce the
> amount of code in the initrd?

Yes it does, see the code in the Novell Moblin images for an example of
how to use devtmpfs with udev for how to do this.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
> Andi Kleen wrote:
> > Greg KH <greg@kroah.com> writes:
> > > It makes the userspace boot process much simpler and easier to maintain,
> > > as well as providing a way to handle rescue disks and images trivially,
> > > and it makes the kernel _less_ dependant on the early userspace bootup
> > > scripts.
> >
> > As a initrd less kernel user I can really only agree: getting rid
> > of the udev-in-initrd requirement would be a big step forward
> > in usability. Typically I always have to pre populate
> > a on disk /dev manually first to get my kernels to boot.
> 
> Oh good, I thought I was the only one doing that.
> 
> The reason I don't like udev is that it's just to slow; something like a 5-10s 
> delay on each boot.  No idea why it should be so slow, but it's probably 
> probing the kernel for all available devices at boot, when it could be much 
> quicker by probing for the device on access.

Like Kay stated, this sounds like a misconfiguration of your distro's
udev setup, as the ones I use (openSUSE and Gentoo) do not have this
problem at all.

Please work with your distro and the people on the
linux-hotplug@vger.kernel.org mailing list to help resolve this issue.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
> > Andi Kleen wrote:
> > > Greg KH <greg@kroah.com> writes:
> > > > It makes the userspace boot process much simpler and easier to
> > > > maintain, as well as providing a way to handle rescue disks and
> > > > images trivially, and it makes the kernel _less_ dependant on the
> > > > early userspace bootup scripts.
> > >
> > > As a initrd less kernel user I can really only agree: getting rid
> > > of the udev-in-initrd requirement would be a big step forward
> > > in usability. Typically I always have to pre populate
> > > a on disk /dev manually first to get my kernels to boot.
> >
> > Oh good, I thought I was the only one doing that.
> >
> > The reason I don't like udev is that it's just to slow; something like a
> > 5-10s delay on each boot.  No idea why it should be so slow, but it's
> > probably probing the kernel for all available devices at boot, when it
> > could be much quicker by probing for the device on access.
>
> Like Kay stated, this sounds like a misconfiguration of your distro's
> udev setup, as the ones I use (openSUSE and Gentoo) do not have this
> problem at all.

Maybe they are using the same trick as Ubuntu and Debian, as they run udev in 
the background to hide the slowness.  Both Fedora and Mandriva run udev in 
the foreground where the slowness is visible.

So really, if devtmpfs compares to udev speeds then this just looks like a 
devfs comeback.  Remember, devfs was really slow.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
> > > Andi Kleen wrote:
> > > > Greg KH <greg@kroah.com> writes:
> > > > > It makes the userspace boot process much simpler and easier to
> > > > > maintain, as well as providing a way to handle rescue disks and
> > > > > images trivially, and it makes the kernel _less_ dependant on the
> > > > > early userspace bootup scripts.
> > > >
> > > > As a initrd less kernel user I can really only agree: getting rid
> > > > of the udev-in-initrd requirement would be a big step forward
> > > > in usability. Typically I always have to pre populate
> > > > a on disk /dev manually first to get my kernels to boot.
> > >
> > > Oh good, I thought I was the only one doing that.
> > >
> > > The reason I don't like udev is that it's just to slow; something like a
> > > 5-10s delay on each boot.  No idea why it should be so slow, but it's
> > > probably probing the kernel for all available devices at boot, when it
> > > could be much quicker by probing for the device on access.
> >
> > Like Kay stated, this sounds like a misconfiguration of your distro's
> > udev setup, as the ones I use (openSUSE and Gentoo) do not have this
> > problem at all.
> 
> Maybe they are using the same trick as Ubuntu and Debian, as they run udev in 
> the background to hide the slowness.  Both Fedora and Mandriva run udev in 
> the foreground where the slowness is visible.

No, Gentoo and openSUSE do not run udev in the background.  It's all due
to the different scripts the udev rules call.  Fedora was known for
having some pretty horrible scripts in older releases, which have
hopefully been fixed in the latest releases.

> So really, if devtmpfs compares to udev speeds then this just looks like a 
> devfs comeback.  Remember, devfs was really slow.

Again, there is no "speed" for devtmpfs on its own, the device nodes
just appear when the devices are added to the kernel, the speed of that
depends on the device discovery within the kernel, nothing else.

And devfs was slow?  How was that measured?  That's not why it was
removed from the kernel, that was due to a wide variety of other
reasons.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Thu, Aug 06, 2009 at 02:19:23AM +0200, Kay Sievers wrote:
> On Thu, Aug 6, 2009 at 02:06, Greg KH<greg@kroah.com> wrote:
> > On Wed, Aug 05, 2009 at 09:55:49PM +0100, Alan Jenkins wrote:
> 
> >> > +                   err = vfs_mkdir(nd.path.dentry->d_inode,
> >> > +                                   dentry, 0775);
> >>
> >> Is there a typo here?  I think the mode should be 0755.   0755 is used
> >> below, and that does fit better with the 0600 mode for device nodes.
> >
> > Yeah, I think you are correct.  Kay, any objection to me making this
> > change?
> 
> No, sure no objection. It sounds right to use 0755.
> I was just waiting if more things to fix come up. :)

I've made this fix in the version in my tree now.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> > So really, if devtmpfs compares to udev speeds then this just looks like
> > a devfs comeback.  Remember, devfs was really slow.
>
> Again, there is no "speed" for devtmpfs on its own, the device nodes
> just appear when the devices are added to the kernel, the speed of that
> depends on the device discovery within the kernel, nothing else.

So on bootup this would mean a lot of discovery.

I think we could get some big speedup, by just dumping the possible 
non-realized device list on bootup, and then just refine it on physical 
access.  This could make devtmpfs an acceptable replacement to static /dev.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Fri, Aug 07, 2009 at 07:03:40AM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> > > So really, if devtmpfs compares to udev speeds then this just looks like
> > > a devfs comeback.  Remember, devfs was really slow.
> >
> > Again, there is no "speed" for devtmpfs on its own, the device nodes
> > just appear when the devices are added to the kernel, the speed of that
> > depends on the device discovery within the kernel, nothing else.
> 
> So on bootup this would mean a lot of discovery.

Yes, all of this happens within the kernel, like normal.  What are you
getting at?

> I think we could get some big speedup, by just dumping the possible 
> non-realized device list on bootup, and then just refine it on physical 
> access.  This could make devtmpfs an acceptable replacement to static /dev.

Um, that's exactly what devtmpfs does, it creates the nodes based on
the fact that the devices were physically (or virtually for some
devices) discovered and registered with the kernel.  This happens at the
same time the existing uevents are generated and sent out to userspace.

I think you are getting very confused here as to what is going on,
perhaps you should read the code a bit more to understand it better.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Fri, Aug 07, 2009 at 07:03:40AM +0300, Al Boldi wrote:
> > Greg KH wrote:
> > > On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> > > > So really, if devtmpfs compares to udev speeds then this just looks
> > > > like a devfs comeback.  Remember, devfs was really slow.
> > >
> > > Again, there is no "speed" for devtmpfs on its own, the device nodes
> > > just appear when the devices are added to the kernel, the speed of that
> > > depends on the device discovery within the kernel, nothing else.
> >
> > So on bootup this would mean a lot of discovery.
>
> Yes, all of this happens within the kernel, like normal.  What are you
> getting at?

I am getting at boot delay.  A lot of discovery means a lot of delay.
A lot of delay means people will stick with static /dev.

> > I think we could get some big speedup, by just dumping the possible
> > non-realized device list on bootup, and then just refine it on physical
> > access.  This could make devtmpfs an acceptable replacement to static
> > /dev.
>
> Um, that's exactly what devtmpfs does, it creates the nodes based on
> the fact that the devices were physically (or virtually for some
> devices) discovered and registered with the kernel.  This happens at the
> same time the existing uevents are generated and sent out to userspace.

The question is, how fast can devtmpfs get the device list from the kernel on 
bootup?  How much faster than udev?  How much slower than static /dev?


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Fri, Aug 07, 2009 at 07:03:40AM +0300, Al Boldi wrote:
> > > Greg KH wrote:
> > > > On Thu, Aug 06, 2009 at 11:18:05PM +0300, Al Boldi wrote:
> > > > > So really, if devtmpfs compares to udev speeds then this just looks
> > > > > like a devfs comeback.  Remember, devfs was really slow.
> > > >
> > > > Again, there is no "speed" for devtmpfs on its own, the device nodes
> > > > just appear when the devices are added to the kernel, the speed of that
> > > > depends on the device discovery within the kernel, nothing else.
> > >
> > > So on bootup this would mean a lot of discovery.
> >
> > Yes, all of this happens within the kernel, like normal.  What are you
> > getting at?
> 
> I am getting at boot delay.  A lot of discovery means a lot of delay.
> A lot of delay means people will stick with static /dev.

Um, again, I don't think you understand this patch at all.

> > > I think we could get some big speedup, by just dumping the possible
> > > non-realized device list on bootup, and then just refine it on physical
> > > access.  This could make devtmpfs an acceptable replacement to static
> > > /dev.
> >
> > Um, that's exactly what devtmpfs does, it creates the nodes based on
> > the fact that the devices were physically (or virtually for some
> > devices) discovered and registered with the kernel.  This happens at the
> > same time the existing uevents are generated and sent out to userspace.
> 
> The question is, how fast can devtmpfs get the device list from the kernel on 
> bootup?  How much faster than udev?  How much slower than static /dev?

It's much faster than udev, and is equivalent to a static /dev with the
exception that the group and permission settings that you are used to.
udev then needs to come along and make those settings, but that's so
frickin fast it's amazing.

So, test it out and see if you want to verify this.  The developers at
suse, red hat, and ubuntu that do this kind of work did validate this
and put their name on this patch.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> It's much faster than udev, and is equivalent to a static /dev with the
> exception that the group and permission settings that you are used to.
> udev then needs to come along and make those settings, but that's so
> frickin fast it's amazing.

Sounds great!

> So, test it out and see if you want to verify this.

Ok, can you post a patch against .30?


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Fri, Aug 07, 2009 at 03:49:21PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > It's much faster than udev, and is equivalent to a static /dev with the
> > exception that the group and permission settings that you are used to.
> > udev then needs to come along and make those settings, but that's so
> > frickin fast it's amazing.
> 
> Sounds great!
> 
> > So, test it out and see if you want to verify this.
> 
> Ok, can you post a patch against .30?

If you look in the lkml archives, the first versions of this were posted
against .30 if you wish to try them out.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Phil Turmel]

Greg KH wrote:
> On Thu, Aug 06, 2009 at 12:20:58PM -0400, David Dillow wrote:
>> On Thu, 2009-08-06 at 17:46 +0200, Andi Kleen wrote:
>>> Greg KH <greg@kroah.com> writes:
>>>> It makes the userspace boot process much simpler and easier to maintain,
>>>> as well as providing a way to handle rescue disks and images trivially,
>>>> and it makes the kernel _less_ dependant on the early userspace bootup
>>>> scripts.
>>> As a initrd less kernel user I can really only agree: getting rid
>>> of the udev-in-initrd requirement would be a big step forward
>>> in usability. Typically I always have to pre populate 
>>> a on disk /dev manually first to get my kernels to boot.
>> If you use mount by label or UUID, you still need udev (or other tools)
>> in the initrd to find the right disk, correct?
> 
> Yes, you would.
> 

Might be straying off-topic here, but I find software raid to be 
particularly useful in this case.  I've been using it on my home server 
for a few years now, including through the transition from ide to 
libata.  The kernel autostart for md devices has been rock-solid, and 
successfully hides the real device name.  No initramfs required.

You might want to adapt the md+lvm setup from the gentoo docs [1], even 
if you only have one disk (degraded mirror).  The only gotcha I've 
encountered was forgetting to set up grub after replacing a failed disk, 
and it happened to be first in line in the BIOS.  Didn't notice 'till an 
extended power outage forced a reboot.

Phil

[1] http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Chris Friesen]

Greg KH wrote:
> On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:

>> The question is, how fast can devtmpfs get the device list from the kernel on 
>> bootup?  How much faster than udev?  How much slower than static /dev?
> 
> It's much faster than udev, and is equivalent to a static /dev with the
> exception that the group and permission settings that you are used to.
> udev then needs to come along and make those settings, but that's so
> frickin fast it's amazing.

Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
really considered "much faster"?

I do agree that it makes sense to do this, but more from an elegance
view than a performance one.

Chris

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Kay Sievers]

On Fri, Aug 7, 2009 at 17:51, Chris Friesen<cfriesen@nortel.com> wrote:
> Greg KH wrote:
>> On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
>
>>> The question is, how fast can devtmpfs get the device list from the kernel on
>>> bootup?  How much faster than udev?  How much slower than static /dev?
>>
>> It's much faster than udev, and is equivalent to a static /dev with the
>> exception that the group and permission settings that you are used to.
>> udev then needs to come along and make those settings, but that's so
>> frickin fast it's amazing.
>
> Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
> really considered "much faster"?

The kernel boots up and mounts the root filesystem in less than a
second these days. :)

> I do agree that it makes sense to do this, but more from an elegance
> view than a performance one.

That's right. The possible speedups are mainly a side-effect of the
simplicity we get by having the kernel providing us the the nodes
without having hard userspace synchronization points early at bootup.

The init=/bin/sh with a fully working and correctly, regarding the
dynamic major/minor numbers, populated /dev is alone reason enough to
do that, I think.

Also things like "modprobe loop; losetup /dev/loop0" will just work,
which do not work reliably today without waiting for userspace to
create the nodes.

Kay

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Chris Friesen wrote:
> Greg KH wrote:
> > On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
> >> The question is, how fast can devtmpfs get the device list from the
> >> kernel on bootup?  How much faster than udev?  How much slower than
> >> static /dev?
> >
> > It's much faster than udev, and is equivalent to a static /dev with the
> > exception that the group and permission settings that you are used to.
> > udev then needs to come along and make those settings, but that's so
> > frickin fast it's amazing.
>
> Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
> really considered "much faster"?
>
> I do agree that it makes sense to do this, but more from an elegance
> view than a performance one.

It's definitely more elegant, but at what cost?

For devtmpfs to be a realistic replacement for static /dev, it has to be 
comparable to static /dev in both speed and size.  WRT speed, there should be 
no  slowdown and it should be just as fast as a "tar -xp < dev.tar".  WRT 
size, it should not be dependent on hotplug, and instead offer hotplug as an 
option.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> Chris Friesen wrote:
> > Greg KH wrote:
> > > On Fri, Aug 07, 2009 at 08:04:08AM +0300, Al Boldi wrote:
> > >> The question is, how fast can devtmpfs get the device list from the
> > >> kernel on bootup?  How much faster than udev?  How much slower than
> > >> static /dev?
> > >
> > > It's much faster than udev, and is equivalent to a static /dev with the
> > > exception that the group and permission settings that you are used to.
> > > udev then needs to come along and make those settings, but that's so
> > > frickin fast it's amazing.
> >
> > Earlier in the thread you indicated a 0.5sec speedup over udev.  Is that
> > really considered "much faster"?
> >
> > I do agree that it makes sense to do this, but more from an elegance
> > view than a performance one.
> 
> It's definitely more elegant, but at what cost?

You've seen the patch, you tell me :)

> For devtmpfs to be a realistic replacement for static /dev, it has to
> be comparable to static /dev in both speed and size.

Since when is this requirement necessary?  You want something for free
in both speed and size?  Well, you got it in speed, but not size, it
will take up memory that is swapable, and a tiny ammount of non-swapable
kernel memory for the code.

> WRT speed, there should be no  slowdown and it should be just as fast
> as a "tar -xp < dev.tar".

Again, where is this requirement coming from?

Have you timed devtmpfs?  Have you timed your tar extraction?  What is
the difference, and since when does anyone use tar of a static dev tree
at boot time?

> WRT size, it should not be dependent on hotplug, and instead offer
> hotplug as an option.

Um, again, who made up such a requirement?  Are you running systems
today with CONFIG_HOTPLUG disabled?  If so, how well is that working for
you?

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > For devtmpfs to be a realistic replacement for static /dev, it has to
> > be comparable to static /dev in both speed and size.
>
> Since when is this requirement necessary?  You want something for free
> in both speed and size?  Well, you got it in speed, but not size, it
> will take up memory that is swapable, and a tiny ammount of non-swapable
> kernel memory for the code.

Not so tiny when you count in the hotplug dependency.

> > WRT speed, there should be no  slowdown and it should be just as fast
> > as a "tar -xp < dev.tar".
>
> Again, where is this requirement coming from?
>
> Have you timed devtmpfs?

Not yet, I am still waiting for the latest patch against .30.

> > WRT size, it should not be dependent on hotplug, and instead offer
> > hotplug as an option.
>
> Um, again, who made up such a requirement?  Are you running systems
> today with CONFIG_HOTPLUG disabled?  If so, how well is that working for
> you?

It's working out quite well.  I don't like hotplug, it's too slow.  I always 
turn it and module-autoloading off, to achieve a much more responsive system.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Sat, Aug 08, 2009 at 12:14:39PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > > For devtmpfs to be a realistic replacement for static /dev, it has to
> > > be comparable to static /dev in both speed and size.
> >
> > Since when is this requirement necessary?  You want something for free
> > in both speed and size?  Well, you got it in speed, but not size, it
> > will take up memory that is swapable, and a tiny ammount of non-swapable
> > kernel memory for the code.
> 
> Not so tiny when you count in the hotplug dependency.

devtmpfs does not rely on hotplug at all.

> > > WRT speed, there should be no  slowdown and it should be just as fast
> > > as a "tar -xp < dev.tar".
> >
> > Again, where is this requirement coming from?
> >
> > Have you timed devtmpfs?
> 
> Not yet, I am still waiting for the latest patch against .30.

I already pointed you at it.

> > > WRT size, it should not be dependent on hotplug, and instead offer
> > > hotplug as an option.
> >
> > Um, again, who made up such a requirement?  Are you running systems
> > today with CONFIG_HOTPLUG disabled?  If so, how well is that working for
> > you?
> 
> It's working out quite well.  I don't like hotplug, it's too slow.  I always 
> turn it and module-autoloading off, to achieve a much more responsive system.

What becomes "more responsive"?  What is too slow?

Anyway, this is quite off-topic for the original patch.  If you have
problems/issues with udev and CONFIG_HOTPLUG, let's take that to the
linux-hotplug@vger.kernel.org list.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Sat, Aug 08, 2009 at 12:14:39PM +0300, Al Boldi wrote:
> > Greg KH wrote:
> > > On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > > > For devtmpfs to be a realistic replacement for static /dev, it has to
> > > > be comparable to static /dev in both speed and size.
> > >
> > > Since when is this requirement necessary?  You want something for free
> > > in both speed and size?  Well, you got it in speed, but not size, it
> > > will take up memory that is swapable, and a tiny ammount of
> > > non-swapable kernel memory for the code.
> >
> > Not so tiny when you count in the hotplug dependency.
>
> devtmpfs does not rely on hotplug at all.

Are you sure?

This is from the patch of this thread:
> +config DEVTMPFS
> +       bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
> +       depends on HOTPLUG && SHMEM && TMPFS


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Arjan van de Ven]

On Wed, 5 Aug 2009 11:28:05 -0700
Greg KH <greg@kroah.com> wrote:
> > and Arjan (who is doing about the fastest Linux boot anyone has and
> > has better data than anyone else)
> 
> We did this work based on Arjan's work.  It solves a problem that
> Moblin has as well, which is why Novell is using it for their
> Moblin-based images they are shipping.  It makes things go faster,
> with a simpler userspace codepath, and we have the numbers as have
> been previously posted.

Uhm.

> > plus 
> > 
> > > Eric has shown that just making the nodes is 0.06 seconds with
> > > todays sysfs interface, and there is room for improvement,
> 
> A 0.06 speedup is still a speedup, right?  :)

it really is only this much.
Do we need to post the program again that we use to make all dev nodes
based on sysfs ? Including the flexibility to have non-default owners
and permissions?



 
> Seriously, we saw much more than that, about 0.5 what I last
> remember, Kay?

I would find that hard to believe, there isn't 0.5 on the table
any which way you look at it.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Thu, 2009-08-06 at 11:31 -0700, Greg KH wrote:
> On Thu, Aug 06, 2009 at 12:20:58PM -0400, David Dillow wrote:
> > If you use mount by label or UUID, you still need udev (or other tools)
> > in the initrd to find the right disk, correct?
> 
> Yes, you would.
> 
> > And for distros that want to support that, does this really reduce the
> > amount of code in the initrd?
> 
> Yes it does, see the code in the Novell Moblin images for an example of
> how to use devtmpfs with udev for how to do this.

I followed up with Greg offline to make sure I was looking at the right
thing, but the upshot is that Moblin does not use an initrd and devtmpfs
does not in any way reduce the amount of code for those distros that
want to support more than the root=/dev/blah syntax.

Given Eric and Arjan's numbers about the time it takes to populate /dev
from /sys -- pointing the speed problem squarely at udev or the ruleset
-- I don't see much of a win for devtmpfs other than avoiding a
static /dev to make init=/bin/sh work. You cannot rely on it for a
hotplug disk such as USB, as it doesn't do the root=LABEL=usbroot that
you'd want to do since the location is not stable.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Pavel Machek]

Hi!

> --- /dev/null
> +++ b/drivers/base/devtmpfs.c
> @@ -0,0 +1,367 @@
> +/*
> + * devtmpfs - kernel-maintained tmpfs-based /dev
> + *
> + * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
> + *

I'd expect GPL notice here...

> +#if defined CONFIG_DEVTMPFS_MOUNT
> +static int dev_mount = 1;
> +#else
> +static int dev_mount;
> +#endif


A bit too many config options?

> +#ifdef CONFIG_BLOCK
> +static inline int is_blockdev(struct device *dev)
> +{
> +	return dev->class == &block_class;
> +}
> +#else
> +static inline int is_blockdev(struct device *dev) { return 0; }

Should this go to header somewhere?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

On Thu, 2009-08-06 at 23:18 +0300, Al Boldi wrote:

> Maybe they are using the same trick as Ubuntu and Debian, as they run udev in 
> the background to hide the slowness.  Both Fedora and Mandriva run udev in 
> the foreground where the slowness is visible.
> 
Ubuntu does not run udev in the background.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Thu, 2009-08-06 at 12:20 -0400, David Dillow wrote:

> On Thu, 2009-08-06 at 17:46 +0200, Andi Kleen wrote:
> > Greg KH <greg@kroah.com> writes:
> > >
> > > It makes the userspace boot process much simpler and easier to maintain,
> > > as well as providing a way to handle rescue disks and images trivially,
> > > and it makes the kernel _less_ dependant on the early userspace bootup
> > > scripts.
> > 
> > As a initrd less kernel user I can really only agree: getting rid
> > of the udev-in-initrd requirement would be a big step forward
> > in usability. Typically I always have to pre populate 
> > a on disk /dev manually first to get my kernels to boot.
> 
> If you use mount by label or UUID, you still need udev (or other tools)
> in the initrd to find the right disk, correct? And for distros that want
> to support that, does this really reduce the amount of code in the
> initrd?
> 
Distros would be then free to experiment with just running "blkid" in
the initramfs to find the root filesystem, rather than the udev daemon
(which runs blkid itself)

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Harald Hoyer]

On 08/06/2009 10:18 PM, Al Boldi wrote:
> Greg KH wrote:
>> On Thu, Aug 06, 2009 at 08:06:16PM +0300, Al Boldi wrote:
>>> Andi Kleen wrote:
>>>> Greg KH<greg@kroah.com>  writes:
>>>>> It makes the userspace boot process much simpler and easier to
>>>>> maintain, as well as providing a way to handle rescue disks and
>>>>> images trivially, and it makes the kernel _less_ dependant on the
>>>>> early userspace bootup scripts.
>>>> As a initrd less kernel user I can really only agree: getting rid
>>>> of the udev-in-initrd requirement would be a big step forward
>>>> in usability. Typically I always have to pre populate
>>>> a on disk /dev manually first to get my kernels to boot.
>>> Oh good, I thought I was the only one doing that.
>>>
>>> The reason I don't like udev is that it's just to slow; something like a
>>> 5-10s delay on each boot.  No idea why it should be so slow, but it's
>>> probably probing the kernel for all available devices at boot, when it
>>> could be much quicker by probing for the device on access.
>> Like Kay stated, this sounds like a misconfiguration of your distro's
>> udev setup, as the ones I use (openSUSE and Gentoo) do not have this
>> problem at all.
>
> Maybe they are using the same trick as Ubuntu and Debian, as they run udev in
> the background to hide the slowness.  Both Fedora and Mandriva run udev in
> the foreground where the slowness is visible.

On Fedora parallel to udev, readahead is running, which makes you think udev is 
slow, but in the end readahead speeds up the boot process by 10%.

>
> So really, if devtmpfs compares to udev speeds then this just looks like a
> devfs comeback.  Remember, devfs was really slow.
>
>
> Thanks!
>
> --
> Al
>

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Scott James Remnant wrote:
> On Thu, 2009-08-06 at 23:18 +0300, Al Boldi wrote:
> > Maybe they are using the same trick as Ubuntu and Debian, as they run
> > udev in the background to hide the slowness.  Both Fedora and Mandriva
> > run udev in the foreground where the slowness is visible.
>
> Ubuntu does not run udev in the background.

I put a date timestamp at the beginning and end of the start command of 
init.d/udev, and when you stop and then start init.d/udev it shows a ~5s 
delay.  At boot I don't see this delay, but instead see the initial date 
stamp, then a flurry of parallel activity, then the final date stamp, which 
shows the ~5s delay.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Mon, 2009-08-10 at 15:05 +0300, Al Boldi wrote:

> Scott James Remnant wrote:
> > On Thu, 2009-08-06 at 23:18 +0300, Al Boldi wrote:
> > > Maybe they are using the same trick as Ubuntu and Debian, as they run
> > > udev in the background to hide the slowness.  Both Fedora and Mandriva
> > > run udev in the foreground where the slowness is visible.
> >
> > Ubuntu does not run udev in the background.
> 
> I put a date timestamp at the beginning and end of the start command of 
> init.d/udev, and when you stop and then start init.d/udev it shows a ~5s 
> delay.  At boot I don't see this delay, but instead see the initial date 
> stamp, then a flurry of parallel activity, then the final date stamp, which 
> shows the ~5s delay.
> 
That flurry of activity is the things that udev does during boot that
takes the 5s.

Right now we have to block until all udev activity is complete, to
ensure that /dev is populated.  This patch is one solution to that
problem.

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Sat, Aug 08, 2009 at 07:07:56PM -0400, David Dillow wrote:
> On Thu, 2009-08-06 at 11:31 -0700, Greg KH wrote:
> > On Thu, Aug 06, 2009 at 12:20:58PM -0400, David Dillow wrote:
> > > If you use mount by label or UUID, you still need udev (or other tools)
> > > in the initrd to find the right disk, correct?
> > 
> > Yes, you would.
> > 
> > > And for distros that want to support that, does this really reduce the
> > > amount of code in the initrd?
> > 
> > Yes it does, see the code in the Novell Moblin images for an example of
> > how to use devtmpfs with udev for how to do this.
> 
> I followed up with Greg offline to make sure I was looking at the right
> thing, but the upshot is that Moblin does not use an initrd and devtmpfs
> does not in any way reduce the amount of code for those distros that
> want to support more than the root=/dev/blah syntax.

Like Scott points out, this option now allows distros to use blkid
directly instead of udev if they want to implement things like this
without udev.

> Given Eric and Arjan's numbers about the time it takes to populate /dev
> from /sys -- pointing the speed problem squarely at udev or the ruleset
> -- I don't see much of a win for devtmpfs other than avoiding a
> static /dev to make init=/bin/sh work.

That's a very big win right there, don't you think?  Also, embedded and
rescue disks also would like it for this very reason.

> You cannot rely on it for a hotplug disk such as USB, as it doesn't do
> the root=LABEL=usbroot that you'd want to do since the location is not
> stable.

Again, not all the world requires such labels.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Sat, Aug 08, 2009 at 09:55:24PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Sat, Aug 08, 2009 at 12:14:39PM +0300, Al Boldi wrote:
> > > Greg KH wrote:
> > > > On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > > > > For devtmpfs to be a realistic replacement for static /dev, it has to
> > > > > be comparable to static /dev in both speed and size.
> > > >
> > > > Since when is this requirement necessary?  You want something for free
> > > > in both speed and size?  Well, you got it in speed, but not size, it
> > > > will take up memory that is swapable, and a tiny ammount of
> > > > non-swapable kernel memory for the code.
> > >
> > > Not so tiny when you count in the hotplug dependency.
> >
> > devtmpfs does not rely on hotplug at all.
> 
> Are you sure?
> 
> This is from the patch of this thread:
> > +config DEVTMPFS
> > +       bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
> > +       depends on HOTPLUG && SHMEM && TMPFS

Ah, you're right.

Ok then, since you don't run CONFIG_HOTPLUG kernels, why are you worried
about this code at all?

confused,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Pavel Machek]

On Mon 2009-08-10 09:36:52, Greg KH wrote:
> On Sun, Aug 09, 2009 at 02:09:02PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > --- /dev/null
> > > +++ b/drivers/base/devtmpfs.c
> > > @@ -0,0 +1,367 @@
> > > +/*
> > > + * devtmpfs - kernel-maintained tmpfs-based /dev
> > > + *
> > > + * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
> > > + *
> > 
> > I'd expect GPL notice here...
> 
> But it's not needed, the overall license of the kernel covers it.
> 

Maybe. Maybe not, just add the single line there...

> > > +#if defined CONFIG_DEVTMPFS_MOUNT
> > > +static int dev_mount = 1;
> > > +#else
> > > +static int dev_mount;
> > > +#endif
> > 
> > 
> > A bit too many config options?
> 
> It's only 1 option, is that 1 too many for you?

It is two, and this option duplicates  commandline
option. Maybe its better to use config_cmdline at that point?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Sun, Aug 09, 2009 at 02:09:02PM +0200, Pavel Machek wrote:
> Hi!
> 
> > --- /dev/null
> > +++ b/drivers/base/devtmpfs.c
> > @@ -0,0 +1,367 @@
> > +/*
> > + * devtmpfs - kernel-maintained tmpfs-based /dev
> > + *
> > + * Copyright (C) 2009, Kay Sievers <kay.sievers@vrfy.org>
> > + *
> 
> I'd expect GPL notice here...

But it's not needed, the overall license of the kernel covers it.

> > +#if defined CONFIG_DEVTMPFS_MOUNT
> > +static int dev_mount = 1;
> > +#else
> > +static int dev_mount;
> > +#endif
> 
> 
> A bit too many config options?

It's only 1 option, is that 1 too many for you?

> > +#ifdef CONFIG_BLOCK
> > +static inline int is_blockdev(struct device *dev)
> > +{
> > +	return dev->class == &block_class;
> > +}
> > +#else
> > +static inline int is_blockdev(struct device *dev) { return 0; }
> 
> Should this go to header somewhere?

It could go in device.h, but do others need it?

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Sat, Aug 08, 2009 at 09:55:24PM +0300, Al Boldi wrote:
> > Greg KH wrote:
> > > On Sat, Aug 08, 2009 at 12:14:39PM +0300, Al Boldi wrote:
> > > > Greg KH wrote:
> > > > > On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > > > > > For devtmpfs to be a realistic replacement for static /dev, it
> > > > > > has to be comparable to static /dev in both speed and size.
> > > > >
> > > > > Since when is this requirement necessary?  You want something for
> > > > > free in both speed and size?  Well, you got it in speed, but not
> > > > > size, it will take up memory that is swapable, and a tiny ammount
> > > > > of non-swapable kernel memory for the code.
> > > >
> > > > Not so tiny when you count in the hotplug dependency.
> > >
> > > devtmpfs does not rely on hotplug at all.
> >
> > Are you sure?
> >
> > This is from the patch of this thread:
> > > +config DEVTMPFS
> > > +       bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
> > > +       depends on HOTPLUG && SHMEM && TMPFS
>
> Ah, you're right.
>
> Ok then, since you don't run CONFIG_HOTPLUG kernels, why are you worried
> about this code at all?
>
> confused,

Linux used to be lean and mean which made it fun to work with, and which made 
the switch from the competition easy.  Nowadays I see a lot of bloat going 
into the kernel which may indicate that Linux is starting to run out of 
steam.  devtmpfs seems bloaty due to the hotplug dependency.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Tue, Aug 11, 2009 at 06:48:26AM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Sat, Aug 08, 2009 at 09:55:24PM +0300, Al Boldi wrote:
> > > Greg KH wrote:
> > > > On Sat, Aug 08, 2009 at 12:14:39PM +0300, Al Boldi wrote:
> > > > > Greg KH wrote:
> > > > > > On Sat, Aug 08, 2009 at 12:17:31AM +0300, Al Boldi wrote:
> > > > > > > For devtmpfs to be a realistic replacement for static /dev, it
> > > > > > > has to be comparable to static /dev in both speed and size.
> > > > > >
> > > > > > Since when is this requirement necessary?  You want something for
> > > > > > free in both speed and size?  Well, you got it in speed, but not
> > > > > > size, it will take up memory that is swapable, and a tiny ammount
> > > > > > of non-swapable kernel memory for the code.
> > > > >
> > > > > Not so tiny when you count in the hotplug dependency.
> > > >
> > > > devtmpfs does not rely on hotplug at all.
> > >
> > > Are you sure?
> > >
> > > This is from the patch of this thread:
> > > > +config DEVTMPFS
> > > > +       bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"
> > > > +       depends on HOTPLUG && SHMEM && TMPFS
> >
> > Ah, you're right.
> >
> > Ok then, since you don't run CONFIG_HOTPLUG kernels, why are you worried
> > about this code at all?
> >
> > confused,
> 
> Linux used to be lean and mean which made it fun to work with, and which made 
> the switch from the competition easy.  Nowadays I see a lot of bloat going 
> into the kernel which may indicate that Linux is starting to run out of 
> steam.

That doesn't seem to make sense, if more development is happening, and
our number of contributors, different companies, and rate of change is
increasing, how are we "running out of steam"?

What specific development number is proof of us slowing down?  I see
nothing but the exact, and extreme, opposite thing happening.

> devtmpfs seems bloaty due to the hotplug dependency.

Would you use it if we fix it to remove this dependancy?

Remember, the dependancy is the other way around here, if you don't want
a CONFIG_HOTPLUG system (and honestly, I really can't believe that you
run a system that interacts with the real world in a non-embedded manner
that way), then you do not also have the devtmpfs code.  So your system
will be "light and tight", right?

So what really is your objection here?  That we did not let devtmpfs
work within a CONFIG_HOTPLUG=n type system?  Or that devtmpfs works with
the existing CONFIG_HOTPLUG=y systems (i.e. 99% of the world)?

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Mon, 2009-08-10 at 08:39 -0700, Greg KH wrote:
> On Sat, Aug 08, 2009 at 07:07:56PM -0400, David Dillow wrote:
> > I followed up with Greg offline to make sure I was looking at the right
> > thing, but the upshot is that Moblin does not use an initrd and devtmpfs
> > does not in any way reduce the amount of code for those distros that
> > want to support more than the root=/dev/blah syntax.
> 
> Like Scott points out, this option now allows distros to use blkid
> directly instead of udev if they want to implement things like this
> without udev.

But they already have that functionality -- RedHat has been doing it for
ages, without devtmpfs. No new kernel code needed.

> > Given Eric and Arjan's numbers about the time it takes to populate /dev
> > from /sys -- pointing the speed problem squarely at udev or the ruleset
> > -- I don't see much of a win for devtmpfs other than avoiding a
> > static /dev to make init=/bin/sh work.
> 
> That's a very big win right there, don't you think?

No, not really. It isn't hard to make a static /dev, or a rescue initrd
for the cases with dynamic device numbers.

> Also, embedded and
> rescue disks also would like it for this very reason.

As a former embedded developer, I'd rather not waste kernel space on
something I can throw away when I've booted. I know where my root is,
and can statically populate /dev. Now, perhaps more embedded devices are
moving to use USB for their root, but then it would seem to make more
sense to use Eric/Arjan's program to populate /dev and do blk_id if I
need to find a label or UUID, and then I can reuse the memory when I'm
done. Perhaps I can find it by path and avoid the blk_id, but I still
can do that without more kernel code.

And I realize that we're not talking about a lot of kernel memory here,
so it depends on one's definition of waste.

> > You cannot rely on it for a hotplug disk such as USB, as it doesn't do
> > the root=LABEL=usbroot that you'd want to do since the location is not
> > stable.
> 
> Again, not all the world requires such labels.

Sure. But it seems the world can get what the best of both worlds from a
simple program to populate /dev from sysfs.

An interesting experiment may be time a boot to initial user space with
and without devtmpfs -- and compare the difference to Eric/Arjan's
program on the same hardware. I wonder how much is really saved.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Andi Kleen]

> No, not really. It isn't hard to make a static /dev, or a rescue initrd
> for the cases with dynamic device numbers.

There's a world between strictly controlled embedded and fully general
distributions.

I want a dynamic /dev, but a fast one that doesn't need initrd or
slows down booting.

This patch seems to be a good way to get that.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> On Tue, Aug 11, 2009 at 06:48:26AM +0300, Al Boldi wrote:
> > Linux used to be lean and mean which made it fun to work with, and which
> > made the switch from the competition easy.  Nowadays I see a lot of bloat
> > going into the kernel which may indicate that Linux is starting to run
> > out of steam.
>
> That doesn't seem to make sense, if more development is happening, and
> our number of contributors, different companies, and rate of change is
> increasing, how are we "running out of steam"?

Running out of "quality steam".  Quantity can never replace Quality.

> What specific development number is proof of us slowing down?  I see
> nothing but the exact, and extreme, opposite thing happening.

The increasing number of regressions are probably cause for concern.

> > devtmpfs seems bloaty due to the hotplug dependency.
>
> Would you use it if we fix it to remove this dependancy?

Yes, if it also compares to static /dev in terms of speed.

> So what really is your objection here?  That we did not let devtmpfs
> work within a CONFIG_HOTPLUG=n type system? 

Yes.

> Or that devtmpfs works with
> the existing CONFIG_HOTPLUG=y systems (i.e. 99% of the world)?

And that should stay an option.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Tue, Aug 11, 2009 at 06:18:16PM +0300, Al Boldi wrote:
> Greg KH wrote:
> > On Tue, Aug 11, 2009 at 06:48:26AM +0300, Al Boldi wrote:
> > > Linux used to be lean and mean which made it fun to work with, and which
> > > made the switch from the competition easy.  Nowadays I see a lot of bloat
> > > going into the kernel which may indicate that Linux is starting to run
> > > out of steam.
> >
> > That doesn't seem to make sense, if more development is happening, and
> > our number of contributors, different companies, and rate of change is
> > increasing, how are we "running out of steam"?
> 
> Running out of "quality steam".  Quantity can never replace Quality.
> 
> > What specific development number is proof of us slowing down?  I see
> > nothing but the exact, and extreme, opposite thing happening.
> 
> The increasing number of regressions are probably cause for concern.

Is that just because we are paying more attention?  Or the fact that our
code base is increasing?  Or something else?

> > > devtmpfs seems bloaty due to the hotplug dependency.
> >
> > Would you use it if we fix it to remove this dependancy?
> 
> Yes, if it also compares to static /dev in terms of speed.

So again, you want something for free?  Good luck.

> > So what really is your objection here?  That we did not let devtmpfs
> > work within a CONFIG_HOTPLUG=n type system? 
> 
> Yes.

Patches gladly welcome.

> > Or that devtmpfs works with
> > the existing CONFIG_HOTPLUG=y systems (i.e. 99% of the world)?
> 
> And that should stay an option.

Again, I don't really believe that you use a CONFIG_HOTPLUG=n system in
the real world, so barring a patch from you or anyone else, I'll leave
it as-is.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Chris Friesen]

Greg KH wrote:

> Again, I don't really believe that you use a CONFIG_HOTPLUG=n system in
> the real world, so barring a patch from you or anyone else, I'll leave
> it as-is.

That seems a bit harsh.  There are lots of embedded devices that don't
need hotplug.

Chris

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Tue, Aug 11, 2009 at 10:04:43AM -0600, Chris Friesen wrote:
> Greg KH wrote:
> 
> > Again, I don't really believe that you use a CONFIG_HOTPLUG=n system in
> > the real world, so barring a patch from you or anyone else, I'll leave
> > it as-is.
> 
> That seems a bit harsh.  There are lots of embedded devices that don't
> need hotplug.

You seem to have missed the previous statements from Al about this topic
which resulted in him ignoring my previous questions about this topic,
and hence, this statement from me.

And yes, of course I know that embedded devices don't need hotplug, but
again, most of them that support any kind of external device being
plugged into them, use that option.

thanks,

greg "context is everything" k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Marcel Holtmann]

Hi Andi,

> > No, not really. It isn't hard to make a static /dev, or a rescue initrd
> > for the cases with dynamic device numbers.
> 
> There's a world between strictly controlled embedded and fully general
> distributions.
> 
> I want a dynamic /dev, but a fast one that doesn't need initrd or
> slows down booting.
> 
> This patch seems to be a good way to get that.

I fully agree.

And more important, if you don't like it, you don't have to use it. It
is just another filesystem and if you wanna stick with tmpfs that is
just fine, too :)

Regards

Marcel

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Tue, 2009-08-11 at 16:55 +0200, Andi Kleen wrote:
> > No, not really. It isn't hard to make a static /dev, or a rescue initrd
> > for the cases with dynamic device numbers.
> 
> There's a world between strictly controlled embedded and fully general
> distributions.

Sure, and I've acknowledged that. But it doesn't mean this needs a
kernel solution.

> I want a dynamic /dev, but a fast one that doesn't need initrd or
> slows down booting.

So use Eric/Arjan's program that does it in 60ms -- you get a
dynamic /dev, no initrd, fast boot, and no kernel changes required.

It remains to be seen how much it costs to do it in user space vs kernel
space. Arjan -- do you have a pointer to your program? Perhaps I can
shake loose some time to test that.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> On Tue, 2009-08-11 at 16:55 +0200, Andi Kleen wrote:
> > > No, not really. It isn't hard to make a static /dev, or a rescue initrd
> > > for the cases with dynamic device numbers.
> > 
> > There's a world between strictly controlled embedded and fully general
> > distributions.
> 
> Sure, and I've acknowledged that. But it doesn't mean this needs a
> kernel solution.
> 
> > I want a dynamic /dev, but a fast one that doesn't need initrd or
> > slows down booting.
> 
> So use Eric/Arjan's program that does it in 60ms -- you get a
> dynamic /dev, no initrd, fast boot, and no kernel changes required.

Their program only handles it for a reconstruction of /dev based on
sysfs one time at boot.  It does not handle things that are added or
discovered by the system after that, you need udev for that.

So it's a great hack for boot time stuff, but not a complete /dev
management replacement like this code can be for numerous systems.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Kay Sievers]

On Mon, Aug 10, 2009 at 17:54, Pavel Machek<pavel@ucw.cz> wrote:

>> > > +#if defined CONFIG_DEVTMPFS_MOUNT
>> > > +static int dev_mount = 1;
>> > > +#else
>> > > +static int dev_mount;
>> > > +#endif
>> >
>> >
>> > A bit too many config options?
>>
>> It's only 1 option, is that 1 too many for you?
>
> It is two, and this option duplicates  commandline
> option. Maybe its better to use config_cmdline at that point?

Sure, if you want to do that, I wouldn't mind to drop the
CONFIG_DEVTMPFS_MOUNT, if we mount it by default, and have the command
line to overwrite the setting.

Kay

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Al Boldi]

Greg KH wrote:
> You seem to have missed the previous statements from Al about this topic
> which resulted in him ignoring my previous questions about this topic,
> and hence, this statement from me.

I tried to answer most of your questions, but if I missed some that you need 
answers for, then please point them out.


Thanks!

--
Al

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Arjan van de Ven]

On Tue, 11 Aug 2009 17:34:33 -0700
Greg KH <greg@kroah.com> wrote:

> On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > On Tue, 2009-08-11 at 16:55 +0200, Andi Kleen wrote:
> > > > No, not really. It isn't hard to make a static /dev, or a
> > > > rescue initrd for the cases with dynamic device numbers.
> > > 
> > > There's a world between strictly controlled embedded and fully
> > > general distributions.
> > 
> > Sure, and I've acknowledged that. But it doesn't mean this needs a
> > kernel solution.
> > 
> > > I want a dynamic /dev, but a fast one that doesn't need initrd or
> > > slows down booting.
> > 
> > So use Eric/Arjan's program that does it in 60ms -- you get a
> > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> 
> Their program only handles it for a reconstruction of /dev based on
> sysfs one time at boot.  It does not handle things that are added or
> discovered by the system after that, you need udev for that.
> 
> So it's a great hack for boot time stuff, but not a complete /dev
> management replacement 

yeah you want udev for that anyway for various reasons...
(not that udev is expensive per se, the expensive part of it is the exec
of modprobe a hundred times... beyond that udev seems pretty cheap to
me)



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Andi Kleen]

> So use Eric/Arjan's program that does it in 60ms -- you get a
> dynamic /dev, no initrd, fast boot, and no kernel changes required.

That would likely need initrd at least on the distro I use which uses
device files very early.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Wed, 2009-08-12 at 09:31 +0200, Andi Kleen wrote:
> > So use Eric/Arjan's program that does it in 60ms -- you get a
> > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> 
> That would likely need initrd at least on the distro I use which uses
> device files very early.

Or mount a tmpfs on /dev and run it right after you mount /proc
and /dev. Doesn't need an initrd.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > So use Eric/Arjan's program that does it in 60ms -- you get a
> > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> 
> Their program only handles it for a reconstruction of /dev based on
> sysfs one time at boot.  It does not handle things that are added or
> discovered by the system after that, you need udev for that.
> 
> So it's a great hack for boot time stuff, but not a complete /dev
> management replacement like this code can be for numerous systems.

What systems would those be? Perhaps it's just too early in the morning
for me, but I'm having a hard time thinking of ones that wouldn't want
to use udev in that case for the event notification, or have their own
handler, such as an embedded system.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 12, 2009 at 08:56:53AM -0400, David Dillow wrote:
> On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> > On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> > 
> > Their program only handles it for a reconstruction of /dev based on
> > sysfs one time at boot.  It does not handle things that are added or
> > discovered by the system after that, you need udev for that.
> > 
> > So it's a great hack for boot time stuff, but not a complete /dev
> > management replacement like this code can be for numerous systems.
> 
> What systems would those be?

Rescue disks, Embedded systems with no local users, servers with no
local users, etc.  Basically anything that you are only root on, and
don't care about group permissions.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Arjan van de Ven]

On Wed, 12 Aug 2009 09:31:52 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> > So use Eric/Arjan's program that does it in 60ms -- you get a
> > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> 
> That would likely need initrd at least on the distro I use which uses
> device files very early.

nah just need to call it early in /etc/rc.sysinit.

initrd is a read herring; distros don't need an initrd
(well except fedora who ship borken with a /dev without
even /dev/console)

initrd and /dev are not related concepts in that sense.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Arjan van de Ven]

On Wed, 12 Aug 2009 06:44:40 -0700
Greg KH <greg@kroah.com> wrote:

> On Wed, Aug 12, 2009 at 08:56:53AM -0400, David Dillow wrote:
> > On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> > > On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > > dynamic /dev, no initrd, fast boot, and no kernel changes
> > > > required.
> > > 
> > > Their program only handles it for a reconstruction of /dev based
> > > on sysfs one time at boot.  It does not handle things that are
> > > added or discovered by the system after that, you need udev for
> > > that.
> > > 
> > > So it's a great hack for boot time stuff, but not a complete /dev
> > > management replacement like this code can be for numerous systems.
> > 
> > What systems would those be?
> 
> Rescue disks, Embedded systems with no local users, servers with no
> local users, etc.  Basically anything that you are only root on, and
> don't care about group permissions.

you're speaking for devtmpfs; the tool we use actually does do group
and owners.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Andi Kleen]

On Wed, Aug 12, 2009 at 07:07:59AM -0700, Arjan van de Ven wrote:
> On Wed, 12 Aug 2009 09:31:52 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> > 
> > That would likely need initrd at least on the distro I use which uses
> > device files very early.
> 
> nah just need to call it early in /etc/rc.sysinit.
> 
> initrd is a read herring; distros don't need an initrd
> (well except fedora who ship borken with a /dev without
> even /dev/console)

SUSE has the same problem. If the on disk /dev is empty
and it typically is out of the box then and there's no
initrd you don't boot.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Wed, 2009-08-12 at 06:44 -0700, Greg KH wrote:
> On Wed, Aug 12, 2009 at 08:56:53AM -0400, David Dillow wrote:
> > On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> > > On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> > > 
> > > Their program only handles it for a reconstruction of /dev based on
> > > sysfs one time at boot.  It does not handle things that are added or
> > > discovered by the system after that, you need udev for that.
> > > 
> > > So it's a great hack for boot time stuff, but not a complete /dev
> > > management replacement like this code can be for numerous systems.
> > 
> > What systems would those be?
> 
> Rescue disks, Embedded systems with no local users, servers with no
> local users, etc.  Basically anything that you are only root on, and
> don't care about group permissions.

We've discussed those, though, and I think most of those fall under
either having full control of their static environment, or would have
something to watch for hotplug events -- udev or a replacement -- and so
would have the ability to create the node from user space.

Rescue disks may be an exception, but they only need a minimal
static /dev and then run a tool to get the initial setup. If you are
expecting an expert to use them, then either running the tool by hand or
as a post-modprobe rule should catch updates. They can also run udev (or
a replacement) with stripped rules if you want to make it friendlier to
non-expert users.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 12, 2009 at 07:09:01AM -0700, Arjan van de Ven wrote:
> On Wed, 12 Aug 2009 06:44:40 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Wed, Aug 12, 2009 at 08:56:53AM -0400, David Dillow wrote:
> > > On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> > > > On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > > > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > > > dynamic /dev, no initrd, fast boot, and no kernel changes
> > > > > required.
> > > > 
> > > > Their program only handles it for a reconstruction of /dev based
> > > > on sysfs one time at boot.  It does not handle things that are
> > > > added or discovered by the system after that, you need udev for
> > > > that.
> > > > 
> > > > So it's a great hack for boot time stuff, but not a complete /dev
> > > > management replacement like this code can be for numerous systems.
> > > 
> > > What systems would those be?
> > 
> > Rescue disks, Embedded systems with no local users, servers with no
> > local users, etc.  Basically anything that you are only root on, and
> > don't care about group permissions.
> 
> you're speaking for devtmpfs; the tool we use actually does do group
> and owners.

Yes I am, sorry if anyone inferred otherwise.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 12, 2009 at 10:39:57AM -0400, David Dillow wrote:
> On Wed, 2009-08-12 at 06:44 -0700, Greg KH wrote:
> > On Wed, Aug 12, 2009 at 08:56:53AM -0400, David Dillow wrote:
> > > On Tue, 2009-08-11 at 17:34 -0700, Greg KH wrote:
> > > > On Tue, Aug 11, 2009 at 08:25:27PM -0400, David Dillow wrote:
> > > > > So use Eric/Arjan's program that does it in 60ms -- you get a
> > > > > dynamic /dev, no initrd, fast boot, and no kernel changes required.
> > > > 
> > > > Their program only handles it for a reconstruction of /dev based on
> > > > sysfs one time at boot.  It does not handle things that are added or
> > > > discovered by the system after that, you need udev for that.
> > > > 
> > > > So it's a great hack for boot time stuff, but not a complete /dev
> > > > management replacement like this code can be for numerous systems.
> > > 
> > > What systems would those be?
> > 
> > Rescue disks, Embedded systems with no local users, servers with no
> > local users, etc.  Basically anything that you are only root on, and
> > don't care about group permissions.
> 
> We've discussed those, though, and I think most of those fall under
> either having full control of their static environment, or would have
> something to watch for hotplug events -- udev or a replacement -- and so
> would have the ability to create the node from user space.

Rescue disks and booting to /init/bash have full control over their
static environment?  I don't think so.

> Rescue disks may be an exception, but they only need a minimal
> static /dev and then run a tool to get the initial setup. If you are
> expecting an expert to use them, then either running the tool by hand or
> as a post-modprobe rule should catch updates. They can also run udev (or
> a replacement) with stripped rules if you want to make it friendlier to
> non-expert users.

Ok, so don't use devtmpfs on your rescue disk, let the rest of us have a
choice :)

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[David Dillow]

On Wed, 2009-08-12 at 08:26 -0700, Greg KH wrote:
> On Wed, Aug 12, 2009 at 10:39:57AM -0400, David Dillow wrote:
> > Rescue disks may be an exception, but they only need a minimal
> > static /dev and then run a tool to get the initial setup. If you are
> > expecting an expert to use them, then either running the tool by hand or
> > as a post-modprobe rule should catch updates. They can also run udev (or
> > a replacement) with stripped rules if you want to make it friendlier to
> > non-expert users.
> 
> Ok, so don't use devtmpfs on your rescue disk, let the rest of us have a
> choice :)

But you have a choice, patch your local kernel. ;)

While my opinion doesn't carry as much weight as yours, Alan's, or
Arjan's, I'm "meh" on this patch. I'm not dead set against it going in,
nor have I seen a compelling reason to do something in kernel space that
can be readily done in user space.

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Robert Schwebel]

On Wed, Aug 05, 2009 at 10:15:13AM -0700, Greg KH wrote:
> Here's the devtmpfs patch again.

As an embedded distro maintainer, I'd really like such an approach. With
ptxdist, we can today build the complete rootfs for an embedded system
without root permissions - just if we want to nfs-root boot the boards
during development, it doesn't work, because you have to create
/dev/console, /dev/null and /dev/zero and that works only for root.

On slow embedded systems (i.e. ARM 200 MHz), note that boot times are
often much slower than on full-blown x86. So any speed improvement is
welcome here as well.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Wed, Aug 12, 2009 at 11:33:48PM +0200, Robert Schwebel wrote:
> On Wed, Aug 05, 2009 at 10:15:13AM -0700, Greg KH wrote:
> > Here's the devtmpfs patch again.
> 
> As an embedded distro maintainer, I'd really like such an approach. With
> ptxdist, we can today build the complete rootfs for an embedded system
> without root permissions - just if we want to nfs-root boot the boards
> during development, it doesn't work, because you have to create
> /dev/console, /dev/null and /dev/zero and that works only for root.
> 
> On slow embedded systems (i.e. ARM 200 MHz), note that boot times are
> often much slower than on full-blown x86. So any speed improvement is
> welcome here as well.

That's good to hear, thanks for the response, I appreciate it.

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Ming Lei]

2009/8/6 Greg KH <greg@kroah.com>:
> Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.

I also prefer devtmpfs.

Base on devtmpfs, we can remove polling for being ready of some
asynchronous root device(usb storage, mmc, ....)
easily before mounting rootfs.

      http://marc.info/?l=linux-kernel&m=124955163908015&w=2
      http://marc.info/?l=linux-kernel&m=124955166508077&w=2

Thanks.

-- 
Lei Ming

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Greg KH]

On Thu, Aug 13, 2009 at 10:18:55AM +0800, Ming Lei wrote:
> 2009/8/6 Greg KH <greg@kroah.com>:
> > Here's the devtmpfs patch again.  For .32 it's a simple and clean patch.
> 
> I also prefer devtmpfs.
> 
> Base on devtmpfs, we can remove polling for being ready of some
> asynchronous root device(usb storage, mmc, ....)
> easily before mounting rootfs.
> 
>       http://marc.info/?l=linux-kernel&m=124955163908015&w=2
>       http://marc.info/?l=linux-kernel&m=124955166508077&w=2

Yes, I like your patches, they are in my "to apply" queue, I wanted to
make sure the devtmpfs original patch was all ok first before applying.
I'll get to them later this week.

thanks,

greg k-h

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Xavier Bestel]

On Wed, 2009-08-12 at 23:33 +0200, Robert Schwebel wrote:
> On Wed, Aug 05, 2009 at 10:15:13AM -0700, Greg KH wrote:
> > Here's the devtmpfs patch again.
> 
> As an embedded distro maintainer, I'd really like such an approach. With
> ptxdist, we can today build the complete rootfs for an embedded system
> without root permissions - just if we want to nfs-root boot the boards
> during development, it doesn't work, because you have to create
> /dev/console, /dev/null and /dev/zero and that works only for root.

Have you tried genext2fs ? It lets you create a filesystem image
complete with device nodes as a normal user.

	Xav

Re: [PATCH] Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

[Robert Schwebel]

On Thu, Aug 13, 2009 at 10:25:40AM +0200, Xavier Bestel wrote:
> On Wed, 2009-08-12 at 23:33 +0200, Robert Schwebel wrote:
> > On Wed, Aug 05, 2009 at 10:15:13AM -0700, Greg KH wrote:
> > > Here's the devtmpfs patch again.
> > 
> > As an embedded distro maintainer, I'd really like such an approach. With
> > ptxdist, we can today build the complete rootfs for an embedded system
> > without root permissions - just if we want to nfs-root boot the boards
> > during development, it doesn't work, because you have to create
> > /dev/console, /dev/null and /dev/zero and that works only for root.
> 
> Have you tried genext2fs ? It lets you create a filesystem image
> complete with device nodes as a normal user.

Creating images is no problem, we use fakeroot to create all kinds of
images (JFFS2, ext2, ext3 etc). But during development, embedded people
often boot their boards with tftpboot/nfsroot in order to do quick
development cycles without re-flashing the hardware, and creating
devicenodes on nfs-exported filesystems doesn't work without root
access.

Since udev, the whole system works almost without pre-created device
nodes, but for console, null and zero there is no real alternative. We
use sudo right now when they are created, but that's a rather uggly
solution.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |