[ANNOUNCE] ndevfs - a "nano" devfs

8 views
Skip to first unread message

Greg KH

unread,
Jun 24, 2005, 4:30:16 AM6/24/05
to
Now I just know I'm going to regret this somehow...

Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
tiny:
$ size fs/ndevfs/inode.o
text data bss dec hex filename
1571 200 8 1779 6f3 fs/ndevfs/inode.o
replacement for devfs for those embedded users who just can't live
without the damm thing. It doesn't allow subdirectories, and only uses
LSB compliant names. But it works, and should be enough for people to
use, if they just can't wean themselves off of the idea of an in-kernel
fs to provide device nodes.

Now, with this, is there still anyone out there who just can't live
without devfs in their kernel?

Damm, the depths I've sunk to these days, I'm such a people pleaser...

Comments? Questions? Criticisms?

I need sleep.

greg k-h
---------------

ndevfs - a "nano" devfs

For embedded people to use since they seem to hate userspace.

Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>

---
drivers/base/class.c | 3
fs/Kconfig | 3
fs/Makefile | 1
fs/ndevfs/Makefile | 4
fs/ndevfs/inode.c | 249 +++++++++++++++++++++++++++++++++++++++++++++++++
fs/partitions/check.c | 6 +
include/linux/ndevfs.h | 13 ++
7 files changed, 279 insertions(+)

--- gregkh-2.6.orig/fs/Kconfig 2005-06-24 01:05:59.000000000 -0700
+++ gregkh-2.6/fs/Kconfig 2005-06-24 01:06:02.000000000 -0700
@@ -1700,6 +1700,9 @@
config RXRPC
tristate

+config NDEV_FS
+ bool "Nano Device File System"
+
endmenu

menu "Partition Types"
--- gregkh-2.6.orig/fs/Makefile 2005-06-24 01:05:59.000000000 -0700
+++ gregkh-2.6/fs/Makefile 2005-06-24 01:06:02.000000000 -0700
@@ -95,3 +95,4 @@
obj-$(CONFIG_HOSTFS) += hostfs/
obj-$(CONFIG_HPPFS) += hppfs/
obj-$(CONFIG_DEBUG_FS) += debugfs/
+obj-$(CONFIG_NDEV_FS) += ndevfs/
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ gregkh-2.6/include/linux/ndevfs.h 2005-06-24 01:06:02.000000000 -0700
@@ -0,0 +1,13 @@
+#ifndef _NDEVFS_H_
+#define _NDEVFS_H_
+
+#if defined(CONFIG_NDEV_FS)
+extern void ndevfs_create(const char *name, dev_t dev, int is_char);
+extern void ndevfs_remove(const char *name);
+#else
+static inline void ndevfs_create(const char *name, dev_t dev, int is_char) {}
+static inline void ndevfs_remove(const char *name) {}
+#endif
+
+#endif
+
--- gregkh-2.6.orig/drivers/base/class.c 2005-06-24 01:05:59.000000000 -0700
+++ gregkh-2.6/drivers/base/class.c 2005-06-24 01:06:02.000000000 -0700
@@ -17,6 +17,7 @@
#include <linux/string.h>
#include <linux/kdev_t.h>
#include <linux/err.h>
+#include <linux/ndevfs.h>
#include "base.h"

#define to_class_attr(_attr) container_of(_attr, struct class_attribute, attr)
@@ -492,6 +493,7 @@
attr->store = NULL;
class_device_create_file(class_dev, attr);
class_dev->devt_attr = attr;
+ ndevfs_create(class_dev->class_id, class_dev->devt, 1);
}

class_device_add_attrs(class_dev);
@@ -595,6 +597,7 @@
class_device_remove_file(class_dev, class_dev->devt_attr);
kfree(class_dev->devt_attr);
class_dev->devt_attr = NULL;
+ ndevfs_remove(class_dev->class_id);
}
class_device_remove_attrs(class_dev);

--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ gregkh-2.6/fs/ndevfs/Makefile 2005-06-24 01:06:02.000000000 -0700
@@ -0,0 +1,4 @@
+ndevfs-objs := inode.o
+
+obj-$(CONFIG_NDEV_FS) += ndevfs.o
+
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ gregkh-2.6/fs/ndevfs/inode.c 2005-06-24 01:06:02.000000000 -0700
@@ -0,0 +1,249 @@
+/*
+ * inode.c - part of ndevfs, a tiny little device file system
+ *
+ * Copyright (C) 2004,2005 Greg Kroah-Hartman <gr...@kroah.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * Written for all of the people out there who just hate userspace solutions.
+ *
+ */
+
+/* uncomment to get debug messages */
+#define DEBUG
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/mount.h>
+#include <linux/pagemap.h>
+#include <linux/init.h>
+#include <linux/namei.h>
+#include <linux/device.h>
+#include <linux/ndevfs.h>
+
+#define MAGIC 0x64756d62
+
+struct entry {
+ struct list_head node;
+ struct dentry *dentry;
+ char name[BUS_ID_SIZE];
+};
+static LIST_HEAD(entries);
+
+static struct vfsmount *mount;
+static int mount_count;
+
+static struct file_operations stupid_file_ops = {
+ .read = generic_file_read,
+ .write = generic_file_write,
+ .mmap = generic_file_mmap,
+ .fsync = simple_sync_file,
+ .llseek = generic_file_llseek,
+};
+
+static struct inode *get_inode(struct super_block *sb, int mode, dev_t dev)
+{
+ struct inode *inode = new_inode(sb);
+
+ if (inode) {
+ inode->i_mode = mode;
+ inode->i_uid = 0;
+ inode->i_gid = 0;
+ inode->i_blksize = PAGE_CACHE_SIZE;
+ inode->i_blocks = 0;
+ inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
+ switch (mode & S_IFMT) {
+ default:
+ init_special_inode(inode, mode, dev);
+ break;
+ case S_IFREG:
+ inode->i_fop = &stupid_file_ops;
+ break;
+ case S_IFDIR:
+ inode->i_op = &simple_dir_inode_operations;
+ inode->i_fop = &simple_dir_operations;
+
+ /* directory inodes start off with i_nlink == 2 (for "." entry) */
+ inode->i_nlink++;
+ break;
+ }
+ }
+ return inode;
+}
+
+/* SMP-safe */
+static int mknod(struct inode *dir, struct dentry *dentry,
+ int mode, dev_t dev)
+{
+ struct inode *inode = get_inode(dir->i_sb, mode, dev);
+ int error = -EPERM;
+
+ if (dentry->d_inode)
+ return -EEXIST;
+
+ if (inode) {
+ d_instantiate(dentry, inode);
+ dget(dentry);
+ error = 0;
+ }
+ return error;
+}
+
+static inline int positive(struct dentry *dentry)
+{
+ return dentry->d_inode && !d_unhashed(dentry);
+}
+
+static int fill_super(struct super_block *sb, void *data, int silent)
+{
+ static struct tree_descr files[] = {{""}};
+
+ return simple_fill_super(sb, MAGIC, files);
+}
+
+static struct super_block *get_sb(struct file_system_type *fs_type,
+ int flags, const char *dev_name,
+ void *data)
+{
+ return get_sb_single(fs_type, flags, data, fill_super);
+}
+
+static void remove(struct dentry *dentry)
+{
+ struct dentry *parent;
+
+ if (!dentry)
+ return;
+
+ parent = dentry->d_parent;
+ if (!parent || !parent->d_inode)
+ return;
+
+ down(&parent->d_inode->i_sem);
+ if (positive(dentry)) {
+ if (dentry->d_inode) {
+ if (S_ISDIR(dentry->d_inode->i_mode))
+ simple_rmdir(parent->d_inode, dentry);
+ else
+ simple_unlink(parent->d_inode, dentry);
+ dput(dentry);
+ }
+ }
+ up(&parent->d_inode->i_sem);
+ simple_release_fs(&mount, &mount_count);
+}
+
+/**
+ * ndevfs_create - create a device node in ndevfs
+ *
+ * @name: the name to create
+ * @dev: the dev_t of the node
+ * @is_char: if the node is a char device or not
+ */
+void ndevfs_create(const char *name, dev_t dev, int is_char)
+{
+ struct dentry *parent;
+ struct dentry *dentry;
+ struct entry *entry;
+ int err;
+ int mode = S_IRUSR | S_IWUSR;
+
+ pr_debug("ndevfs: creating file '%s' with major %d and minor %d\n",
+ name, MAJOR(dev), MINOR(dev));
+
+ if (is_char)
+ mode |= S_IFCHR;
+ else
+ mode |= S_IFBLK;
+
+ err = simple_pin_fs("ndevfs", &mount, &mount_count);
+ if (err)
+ return;
+
+ /* everything is at the root fs, no directories allowed */
+ if (mount && mount->mnt_sb) {
+ parent = mount->mnt_sb->s_root;
+ } else {
+ pr_debug("%s: no parent?\n", __FUNCTION__);
+ goto error;
+ }
+
+ down(&parent->d_inode->i_sem);
+ dentry = lookup_one_len(name, parent, strlen(name));
+ if (!IS_ERR(dentry))
+ err = mknod(parent->d_inode, dentry, mode, dev);
+ else
+ err = PTR_ERR(dentry);
+ up(&parent->d_inode->i_sem);
+
+ if (err)
+ goto error;
+
+ entry = kmalloc(sizeof(struct entry), GFP_KERNEL);
+ if (!entry) {
+ remove(dentry);
+ err = -ENOMEM;
+ goto error;
+ }
+ entry->dentry = dentry;
+ strcpy(&entry->name[0], name);
+ list_add(&entry->node, &entries);
+ return;
+
+error:
+ pr_debug("%s failed with error %d\n", __FUNCTION__, err);
+ simple_release_fs(&mount, &mount_count);
+}
+EXPORT_SYMBOL_GPL(ndevfs_create);
+
+/**
+ * ndevfs_remove - removes the node from the fs
+ *
+ * @name: the name to remove.
+ */
+void ndevfs_remove(const char *name)
+{
+ struct entry *entry;
+ struct dentry *dentry = NULL;
+
+ pr_debug("ndevfs: removing file '%s'\n", name);
+
+ list_for_each_entry(entry, &entries, node) {
+ if (strcmp(name, &entry->name[0]) == 0) {
+ dentry = entry->dentry;
+ break;
+ }
+ }
+ if (!dentry) {
+ pr_debug("%s: can't find %s\n", __FUNCTION__, name);
+ return;
+ }
+ remove (dentry);
+}
+EXPORT_SYMBOL_GPL(ndevfs_remove);
+
+static struct file_system_type fs_type = {
+ .owner = THIS_MODULE,
+ .name = "ndevfs",
+ .get_sb = get_sb,
+ .kill_sb = kill_litter_super,
+};
+
+static int __init ndevfs_init(void)
+{
+ return register_filesystem(&fs_type);
+}
+
+static void __exit ndevfs_exit(void)
+{
+ simple_release_fs(&mount, &mount_count);
+ unregister_filesystem(&fs_type);
+}
+
+core_initcall(ndevfs_init);
+module_exit(ndevfs_exit);
+MODULE_LICENSE("GPL");
+
--- gregkh-2.6.orig/fs/partitions/check.c 2005-06-24 01:05:59.000000000 -0700
+++ gregkh-2.6/fs/partitions/check.c 2005-06-24 01:06:02.000000000 -0700
@@ -18,6 +18,7 @@
#include <linux/fs.h>
#include <linux/kmod.h>
#include <linux/ctype.h>
+#include <linux/ndevfs.h>

#include "check.h"

@@ -273,6 +274,7 @@
p->start_sect = 0;
p->nr_sects = 0;
p->reads = p->writes = p->read_sectors = p->write_sectors = 0;
+ ndevfs_remove(kobject_name(&p->kobj));
kobject_unregister(&p->kobj);
}

@@ -296,6 +298,7 @@
p->kobj.parent = &disk->kobj;
p->kobj.ktype = &ktype_part;
kobject_register(&p->kobj);
+ ndevfs_create(kobject_name(&p->kobj), MKDEV(disk->major, p->partno), 0);
disk->part[part-1] = p;
}

@@ -323,6 +326,8 @@
if ((err = kobject_add(&disk->kobj)))
return;
disk_sysfs_symlinks(disk);
+ ndevfs_create(kobject_name(&disk->kobj),
+ MKDEV(disk->major, disk->first_minor), 0);
kobject_hotplug(&disk->kobj, KOBJ_ADD);

/* No minors to use for partitions */
@@ -420,6 +425,7 @@
sysfs_remove_link(&disk->driverfs_dev->kobj, "block");
put_device(disk->driverfs_dev);
}
+ ndevfs_remove(kobject_name(&disk->kobj));
kobject_hotplug(&disk->kobj, KOBJ_REMOVE);
kobject_del(&disk->kobj);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Tokarev

unread,
Jun 24, 2005, 8:30:13 AM6/24/05
to
Greg KH wrote:
> Now I just know I'm going to regret this somehow...

Why?

Well. I've read several endless discussions about devfs/udev/dev etc.
I've a question still, which has been raised by several other people
too. The question is this: "what is a naming policy?"

Kernel already have some "naming scheme", used internally. Think
about /proc/partitions, /sys nodenames (/sys/block/sda etc), think
about dmesg output (serial: registered device tttS0) etc.
This is just because devices *have* to be named *somehow*.
And, IMHO, there should be a way for the user (or whomever),
when he sees that dmesg/partitions/whatever, to access that
device in /dev.

That same device can have other names too, like
/dev/MyYellowCDBurner or /dev/MyPhotoCamera. I think
*that* is a policy. And there's an internal (in-kernel)
naming scheme. Which has been here for ages, with alot
or programs expected to see "standard" names in /dev
(think how lilo or, worse, mdadm, fails when it can't
find a device listed in /proc/partitions because the
node has been created with different name according
to "policy").

More, with dynamic (or semi-dynamic) /dev, like devfs
or udev provides, the directory isn't cluttered with
alot of unused files anymore (before udev, i was trying
to move grouops of devices into subdirs in /dev, like
moving all scsi disks (sd) to /dev/sd/, with the only
reason: to have less entries in /dev, some of which
can be useful in some future...), it isn't really
that matters if it will have flat namespace. Ok
ok, with 20K scsi devices, it may be problematic
somehow.. i dunno really, a machine with 20K
disks usually have apropriate amount of RAM too).

So, to summarize all that. A dynamic /dev, which
creates/removes nodes using in-kernel naming scheme
(which is here for ages) automatically, and calls
external program to help create "policy"-based
naming -- i don't think it's a bad idea anyway.

> Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> tiny:
> $ size fs/ndevfs/inode.o
> text data bss dec hex filename
> 1571 200 8 1779 6f3 fs/ndevfs/inode.o
> replacement for devfs for those embedded users who just can't live
> without the damm thing. It doesn't allow subdirectories, and only uses
> LSB compliant names. But it works, and should be enough for people to
> use, if they just can't wean themselves off of the idea of an in-kernel
> fs to provide device nodes.
>
> Now, with this, is there still anyone out there who just can't live
> without devfs in their kernel?
>
> Damm, the depths I've sunk to these days, I'm such a people pleaser...
>
> Comments? Questions? Criticisms?

A question. I can't apply this to 2.6.12, it fails in
drivers/base/class.c -- the main portion i think. What's
this patch against?

I'd love to see how it works but.. can't compile it ;)

And another question. Why it isn't possible to use
plain tmpfs for this sort of things? Why to create
another filesystem, instead of just using current
tmpfs and call mknod/unlink on it as appropriate?
This same tmpfs can be used by udev too (to create
that "policy"-based names), and it gives us all
the directories and other stuff...

Thanks.

/mjt

Bill Gatliff

unread,
Jun 24, 2005, 10:40:10 AM6/24/05
to
Greg:

Greg KH wrote:

>Now I just know I'm going to regret this somehow...
>
>

Now, don't hold back on us here. Tell us how you really feel! :^)


b.g.

--
Bill Gatliff
Embedded Linux development and training services.
bg...@billgatliff.com

Steven Rostedt

unread,
Jun 24, 2005, 11:30:11 AM6/24/05
to

On Fri, 24 Jun 2005, Greg KH wrote:

> Now I just know I'm going to regret this somehow...
>


;)

> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ gregkh-2.6/fs/ndevfs/inode.c 2005-06-24 01:06:02.000000000 -0700
> @@ -0,0 +1,249 @@
> +/*
> + * inode.c - part of ndevfs, a tiny little device file system
> + *
> + * Copyright (C) 2004,2005 Greg Kroah-Hartman <gr...@kroah.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * Written for all of the people out there who just hate userspace solutions.
> + *
> + */
> +
> +/* uncomment to get debug messages */
> +#define DEBUG
> +

Don't you mean here "comment to turn off debug messages?" :-)

-- Steve

> +#include <linux/config.h>
> +#include <linux/module.h>
> +#include <linux/fs.h>
> +#include <linux/mount.h>
> +#include <linux/pagemap.h>
> +#include <linux/init.h>
> +#include <linux/namei.h>

Greg KH

unread,
Jun 24, 2005, 11:30:17 AM6/24/05
to
On Fri, Jun 24, 2005 at 04:23:49PM +0400, Michael Tokarev wrote:

<snip>

I'll respond to your comments later, it's too early...

> A question. I can't apply this to 2.6.12, it fails in
> drivers/base/class.c -- the main portion i think. What's
> this patch against?

2.6.12-git5, sorry I should have mentioned that.

> And another question. Why it isn't possible to use
> plain tmpfs for this sort of things?

What do you mean? What's wrong with a ramfs based fs? To use tmpfs
would require a lot more work. But if you want to do it, I'll gladly
take patches :)

> Why to create another filesystem, instead of just using current
> tmpfs and call mknod/unlink on it as appropriate?

Um, that's about all that this code does.

> This same tmpfs can be used by udev too (to create that "policy"-based
> names), and it gives us all the directories and other stuff...

udev doesn't need a kernel specific fs.

thanks,

greg k-h

Greg KH

unread,
Jun 24, 2005, 11:30:11 AM6/24/05
to
On Fri, Jun 24, 2005 at 11:17:02AM -0400, Steven Rostedt wrote:
> > +/* uncomment to get debug messages */
> > +#define DEBUG
> > +
>
> Don't you mean here "comment to turn off debug messages?" :-)

Well, I should have commented out that first, the comment is right, the
code is wrong :)

thanks,

greg k-h

Greg KH

unread,
Jun 24, 2005, 11:30:13 AM6/24/05
to
On Fri, Jun 24, 2005 at 02:43:04PM +0100, tvrtko....@sophos.com wrote:

> On 24/06/2005 09:18:08 linux-kernel-owner wrote:
>
> >Now I just know I'm going to regret this somehow...
>
> You got that right! ;)
>
> >Comments? Questions? Criticisms?
>
> It's cool and small. I like it, and I agree with Michael policy vs. policy
> analisys.

Thanks.

> I applied it to 2.6.12 (of course some manual intervention was needed) and
> are you curious about what happened next? Below are the relevant logs and
> outputs. As you can see, some of them are not working as expected.

Yeah, 2.6.12-git5 was what it was against, sorry I didn't mention that.


> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI: Probing PCI hardware (bus 00)
> ndevfs: creating file '0000:00' with major 0 and minor 0
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
> ndevfs: creating file '0000:01' with major 0 and minor 0
> Boot video device is 0000:01:00.0
> ndevfs: creating file '0000:02' with major 0 and minor 0

Hm, that is odd. That shouldn't happen.

Wait, I think it was due to where you put the class hooks, try it
against Linus's latest tree, it will work better there (in fact, I don't
know if it would work properly in 2.6.12 due to the class driver core
changes.)

Could you try that and let me know if it still has issues?

tvrtko....@sophos.com

unread,
Jun 24, 2005, 11:50:10 AM6/24/05
to
On 24/06/2005 16:23:11 Greg KH wrote:

>> ndevfs: creating file '0000:02' with major 0 and minor 0
>
>Hm, that is odd. That shouldn't happen.
>
>Wait, I think it was due to where you put the class hooks, try it
>against Linus's latest tree, it will work better there (in fact, I don't
>know if it would work properly in 2.6.12 due to the class driver core
>changes.)
>
>Could you try that and let me know if it still has issues?

It was me incorrectly fixing the rejects. If I had looked at it more
carefully I would have got it right the first time. Anyway, I moved the
relevant ndevfs_create in the right 'if' block and now everything is fine.
Am I still using 2.6.12 btw.

Sorry for not letting you know that earlier, I was waiting for my post to
show up so that I can reply to myself.

Michael Tokarev

unread,
Jun 24, 2005, 11:50:05 AM6/24/05
to
Greg KH wrote:
> On Fri, Jun 24, 2005 at 04:23:49PM +0400, Michael Tokarev wrote:
>>And another question. Why it isn't possible to use
>>plain tmpfs for this sort of things?
>
> What do you mean? What's wrong with a ramfs based fs? To use tmpfs
> would require a lot more work. But if you want to do it, I'll gladly
> take patches :)

Hmm. Ramfs and Tmpfs... I mean, we already have several filesystems
which works, and are complete filesystems. Tmpfs is just one of them.

The point is as the following. Instead of creating completely new
filesystem, there should be a possibility to create just a small
layer on top of existing, feature-complete (think directories)
filesystem, like tmpfs, with the only difference is that it's
especially known by the kernel as containing device nodes (where
the kernel should create/delete the nodes), and is mountable as
such (not as any generic tmpfs). When a new device is created,
ndevfs_mknod() (or similar) is called as in your patch, but the
node is created in normal, regular tmpfs, instead of on some
stripped-down filesystem.

This tmpfs will be mountable ofcourse, *and* it will support all
the other normal filesystem operations. But...

>>Why to create another filesystem, instead of just using current
>>tmpfs and call mknod/unlink on it as appropriate?
>
> Um, that's about all that this code does.

....Ah ok. Well. Hmm. So I misread the code it seems.
I thought it does not support directories and symlinks..

>>This same tmpfs can be used by udev too (to create that "policy"-based
>>names), and it gives us all the directories and other stuff...
>
> udev doesn't need a kernel specific fs.

I know. But it should be able to run on top of such an FS
to (at least I don't see why it shouldn't), provided it only
maintains that "policy" names (symlinks) to "canonical" device
nodes (which is easily doable by just stripping config file).

/mjt

Greg KH

unread,
Jun 24, 2005, 12:40:08 PM6/24/05
to
On Fri, Jun 24, 2005 at 04:32:34PM +0100, tvrtko....@sophos.com wrote:
> On 24/06/2005 16:23:11 Greg KH wrote:
>
> >> ndevfs: creating file '0000:02' with major 0 and minor 0
> >
> >Hm, that is odd. That shouldn't happen.
> >
> >Wait, I think it was due to where you put the class hooks, try it
> >against Linus's latest tree, it will work better there (in fact, I don't
> >know if it would work properly in 2.6.12 due to the class driver core
> >changes.)
> >
> >Could you try that and let me know if it still has issues?
>
> It was me incorrectly fixing the rejects. If I had looked at it more
> carefully I would have got it right the first time. Anyway, I moved the
> relevant ndevfs_create in the right 'if' block and now everything is fine.
> Am I still using 2.6.12 btw.

Great, thanks for validating this.

> Sorry for not letting you know that earlier, I was waiting for my post to
> show up so that I can reply to myself.

Your message was too big and was probably rejected by the list.

thanks,

greg k-h

Greg KH

unread,
Jun 24, 2005, 12:40:10 PM6/24/05
to
On Fri, Jun 24, 2005 at 07:40:42PM +0400, Michael Tokarev wrote:
> Greg KH wrote:
> > On Fri, Jun 24, 2005 at 04:23:49PM +0400, Michael Tokarev wrote:
> >>And another question. Why it isn't possible to use
> >>plain tmpfs for this sort of things?
> >
> > What do you mean? What's wrong with a ramfs based fs? To use tmpfs
> > would require a lot more work. But if you want to do it, I'll gladly
> > take patches :)
>
> Hmm. Ramfs and Tmpfs... I mean, we already have several filesystems
> which works, and are complete filesystems. Tmpfs is just one of them.

Heh, I know this quite well :)

> The point is as the following. Instead of creating completely new
> filesystem, there should be a possibility to create just a small
> layer on top of existing, feature-complete (think directories)
> filesystem, like tmpfs, with the only difference is that it's
> especially known by the kernel as containing device nodes (where
> the kernel should create/delete the nodes), and is mountable as
> such (not as any generic tmpfs). When a new device is created,
> ndevfs_mknod() (or similar) is called as in your patch, but the
> node is created in normal, regular tmpfs, instead of on some
> stripped-down filesystem.

Again, that's exactly what this patch does.

> >>Why to create another filesystem, instead of just using current
> >>tmpfs and call mknod/unlink on it as appropriate?
> >
> > Um, that's about all that this code does.
>
> ....Ah ok. Well. Hmm. So I misread the code it seems.
> I thought it does not support directories and symlinks..

It supports it, but I stipped it down to not allow that, I'll have to
add code to enable that, if enough people complain :)

> >>This same tmpfs can be used by udev too (to create that "policy"-based
> >>names), and it gives us all the directories and other stuff...
> >
> > udev doesn't need a kernel specific fs.
>
> I know. But it should be able to run on top of such an FS
> to (at least I don't see why it shouldn't), provided it only
> maintains that "policy" names (symlinks) to "canonical" device
> nodes (which is easily doable by just stripping config file).

I eagerly await your patch to show what you are referring to.

thanks,

greg k-h

Michael Tokarev

unread,
Jun 24, 2005, 1:30:14 PM6/24/05
to
Greg KH wrote:
> Now I just know I'm going to regret this somehow...
>
> Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> tiny:
> $ size fs/ndevfs/inode.o
> text data bss dec hex filename
> 1571 200 8 1779 6f3 fs/ndevfs/inode.o
> replacement for devfs for those embedded users who just can't live
> without the damm thing. It doesn't allow subdirectories, and only uses
> LSB compliant names. But it works, and should be enough for people to
> use, if they just can't wean themselves off of the idea of an in-kernel
> fs to provide device nodes.

Well. Maybe directories really are of no use, but mknod/symlink/unlink
*are* useful. That same mdadm who needs to create /dev/mdX *before*
that device is created? And socket for /dev/log...

And oh, directories.. devpts? Stuff like cciss/... represented in sysfs
like cciss!... ?

I don't see anything wrong with allowing creating/removing files in
the filesystem (except of possible locking issues which can arise) --
in-kernel support just does mknod/unlink on insert/remove, and if
that fails (EEXIST/ENOENT), well, so be it...

And since the whole namespace is now flat, another question comes in:
is there any guarantee the names will not overlap? /dev/ttyS0 and
/dev/usb/ttyS0 (I don't remember which one it was, but I *think* I
saw same names but in different dirs in /dev...)

/mjt

Bill Gatliff

unread,
Jun 24, 2005, 1:40:09 PM6/24/05
to
Greg KH wrote:

>Now I just know I'm going to regret this somehow...
>
>Anyway, here's yet-another-ramfs-based filesystem, ndevfs.
>

Here's your code against vanilla 2.6.12.

I ran it on an ARM machine, was able to successfully mount it and do an
'ls'. Not an exhaustive test, obviously.

Only errors I saw in the output were:

...
Freeing init memory: 100K
ndevfs: creating file 'vcs1' with major 7 and minor 1
ndevfs: creating file 'vcsa1' with major 7 and minor 129
ndevfs: creating file 'vcs1' with major 7 and minor 1
ndevfs_create failed with error -17
ndevfs: creating file 'vcsa1' with major 7 and minor 129
ndevfs_create failed with error -17
...

I don't know what vcs1 and vcsa1 are, not sure I really care... :^)

I moved your Kconfig diff; it was showing up in miscellaneous
filesystems, I put it in pseudo filesystems instead.


b.g.

--
Bill Gatliff
bg...@billgatliff.com
Professional embedded Linux training.

ndevfs-patch

Mike Bell

unread,
Jun 24, 2005, 3:20:10 PM6/24/05
to
On Fri, Jun 24, 2005 at 01:18:08AM -0700, Greg KH wrote:
> Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> tiny:
...

> replacement for devfs for those embedded users who just can't live
> without the damm thing. It doesn't allow subdirectories, and only uses
> LSB compliant names. But it works, and should be enough for people to
> use, if they just can't wean themselves off of the idea of an in-kernel
> fs to provide device nodes.

As far as ideas go, this is pretty much all I asked for. A simple kernel
filesystem to export device nodes with names, rather than just the
numbers as sysfs does. The "detecting non-existant device names" thing
never meant anything to me personally, and if anyone does care this
gives them a simple place to add such a hook - unlike device names I
don't see why such a thing would be difficult to maintain as a patch.

It'll obviously need support for symlinks, directories and mknod. And
I'm not sure you can change the mode/owner of those devices yet. Also, I
have no idea what the device support is like yet (am currently in the
middle of nowhere, getting the latest bk to test this patch with over
my handphone would not be fun) but looking at the bit where it's getting
the names from the device model I can see it encountering problems with
oddly named devices. And any devices which aren't dynamic in udev
obviously aren't going to work with this patch either.

What's the method for bootstrapping this filesystem onto a system? Is
a mount from early userspace the only way you'd accept, or would a
kernel parameter to automount over /dev as devfs does be tolerable?

> Now, with this, is there still anyone out there who just can't live
> without devfs in their kernel?

If devfs could be left alone (disabled, if necessary) until something
like this was working, I would be completely mollified.

> For embedded people to use since they seem to hate userspace.

Userspace killed my father.

Alexey Dobriyan

unread,
Jun 24, 2005, 3:30:17 PM6/24/05
to
On Friday 24 June 2005 12:18, Greg KH wrote:
> --- /dev/null
> +++ gregkh-2.6/fs/ndevfs/inode.c

> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * Written for all of the people out there who just hate userspace solutions.

No. Whining. License. Please. ;-)

J.A. Magallon

unread,
Jun 24, 2005, 6:20:08 PM6/24/05
to

On 06.24, Mike Bell wrote:
> On Fri, Jun 24, 2005 at 01:18:08AM -0700, Greg KH wrote:
> > Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> > tiny:
> ...
> > replacement for devfs for those embedded users who just can't live
> > without the damm thing. It doesn't allow subdirectories, and only uses
> > LSB compliant names. But it works, and should be enough for people to
> > use, if they just can't wean themselves off of the idea of an in-kernel
> > fs to provide device nodes.
>
> As far as ideas go, this is pretty much all I asked for. A simple kernel
> filesystem to export device nodes with names, rather than just the
> numbers as sysfs does. The "detecting non-existant device names" thing
> never meant anything to me personally, and if anyone does care this
> gives them a simple place to add such a hook - unlike device names I
> don't see why such a thing would be difficult to maintain as a patch.
>

I had always asked for the simpler and minimal /dev to let a system boot
and reach udev start, and I think this is even better !!

>
> What's the method for bootstrapping this filesystem onto a system? Is
> a mount from early userspace the only way you'd accept, or would a
> kernel parameter to automount over /dev as devfs does be tolerable?
>

I got sad when I read I did not support directories and so on, because
that meant I could not run udev on it, but I have thought
on an alernative for early userspace:
- mount ndevfs on /mnt
- cp -a /mnt /dev
- umount /mnt
- let init run /etc/rc.d/rc till it gets to mount /dev and start udev

Just a question (kinda newbie's question):

Does ndevfs to be mounted when a device is detected ? Or will it show
all the registered devices when mounted ?

TIA

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam2 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

Kyle Moffett

unread,
Jun 24, 2005, 9:10:06 PM6/24/05
to
One of the things that most annoys me about udev is that I still need
a minimal static dev in order for the system to boot. Could something
like this be used as follows?

1) Boot kernel with an arg "automount_ndevfs", which automounts on /dev

2) Init scripts use console, ttyX, hda, sda, etc from ndevfs

3) Init script for udev does:
# mount -t tmpfs udev /.dev
# udevstart /.dev
# mount --move /.dev /dev
# mount -t ndevfs ndevfs /dev/.kerndev

4) Normal userspace apps use /dev

5) When udev is stopped, it can just umount /dev/.kerndev, then umount
/dev, then the basic stuff should still work.

Ideally ndevfs should support basic subdirectories and symlinks, so that
a simple /dev/pts could be mounted over top of it without any hassle.

Cheers,
Kyle Moffett

--
Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best
answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why
I draw cartoons. It's my life."
-- Charles Shultz

Denis Vlasenko

unread,
Jun 25, 2005, 3:50:08 AM6/25/05
to
On Saturday 25 June 2005 03:57, Kyle Moffett wrote:
> One of the things that most annoys me about udev is that I still need
> a minimal static dev in order for the system to boot. Could something
> like this be used as follows?
>
> 1) Boot kernel with an arg "automount_ndevfs", which automounts on /dev
>
> 2) Init scripts use console, ttyX, hda, sda, etc from ndevfs

Even more magic piled up in kernel? Please no.

I've moved to initrd-basid start, thus I don't need anything on /dev.
My initrd mounts ramfs on /dev and populates it with bare minimum,
then udev kicks in.

With dietlibc/uclibc/busybox, initrd can get ridiculously small :)
--
vda

Matt Mackall

unread,
Jun 25, 2005, 6:20:07 PM6/25/05
to
On Fri, Jun 24, 2005 at 01:18:08AM -0700, Greg KH wrote:
> Now I just know I'm going to regret this somehow...
>
> Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> tiny:
> $ size fs/ndevfs/inode.o
> text data bss dec hex filename
> 1571 200 8 1779 6f3 fs/ndevfs/inode.o
> replacement for devfs for those embedded users who just can't live
> without the damm thing. It doesn't allow subdirectories, and only uses
> LSB compliant names. But it works, and should be enough for people to
> use, if they just can't wean themselves off of the idea of an in-kernel
> fs to provide device nodes.
>
> Now, with this, is there still anyone out there who just can't live
> without devfs in their kernel?
>
> Damm, the depths I've sunk to these days, I'm such a people pleaser...

Hmm. I'm not pleased. Perhaps you're pleasing the wrong people?

What we really need is a short HOWTO that covers:

- Do you really need a dynamic /dev?
- How to embed a static /dev in your embedded kernel with initramfs
- How to add a dynamic /dev to your kernel with udev

--
Mathematics is the supreme nostalgia of our time.

Greg KH

unread,
Jun 25, 2005, 7:50:08 PM6/25/05
to
On Sat, Jun 25, 2005 at 03:15:16PM -0700, Matt Mackall wrote:
> On Fri, Jun 24, 2005 at 01:18:08AM -0700, Greg KH wrote:
> > Now I just know I'm going to regret this somehow...
> >
> > Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> > tiny:
> > $ size fs/ndevfs/inode.o
> > text data bss dec hex filename
> > 1571 200 8 1779 6f3 fs/ndevfs/inode.o
> > replacement for devfs for those embedded users who just can't live
> > without the damm thing. It doesn't allow subdirectories, and only uses
> > LSB compliant names. But it works, and should be enough for people to
> > use, if they just can't wean themselves off of the idea of an in-kernel
> > fs to provide device nodes.
> >
> > Now, with this, is there still anyone out there who just can't live
> > without devfs in their kernel?
> >
> > Damm, the depths I've sunk to these days, I'm such a people pleaser...
>
> Hmm. I'm not pleased. Perhaps you're pleasing the wrong people?

You are so right, I am. I need to be pleasing me, and devfs in the
kernel is not the correct solution. I knew this 4 years ago when Pat
and I started working on the driver core (my main goal was to do it to
support a udev-like solution), and I still know this today.

So no, I'm not going to be submitting this. But what it is, is a nice
proof-of-concept for people who "just can't live without a in-kernel
devfs" to show that it can be done in less than 300 lines of code, and
only 6 hooks (2 functions in 3 different places) in the main kernel
tree. That is managable outside of the main kernel for years, with
almost little to no effort.

> What we really need is a short HOWTO that covers:
>
> - Do you really need a dynamic /dev?
> - How to embed a static /dev in your embedded kernel with initramfs
> - How to add a dynamic /dev to your kernel with udev

Yes, I'm going to start working with some of the people who really know
this stuff (the distro developers who make the whole dynamic boot and
early boot process work correctly) and we will hash out a coheirant
future together, and document it all really well.

But I'm going to wait to do that till next week, the sun is shining, the
beer is cold, and I'm going to relax now...

Thanks for calling me on this, I appreciate it. You weren't the only
one either, which is a good thing.

greg k-h

Russell King

unread,
Jun 26, 2005, 4:30:06 AM6/26/05
to
On Sat, Jun 25, 2005 at 04:43:05PM -0700, Greg KH wrote:
> > What we really need is a short HOWTO that covers:
> >
> > - Do you really need a dynamic /dev?
> > - How to embed a static /dev in your embedded kernel with initramfs
> > - How to add a dynamic /dev to your kernel with udev
>
> Yes, I'm going to start working with some of the people who really know
> this stuff (the distro developers who make the whole dynamic boot and
> early boot process work correctly) and we will hash out a coheirant
> future together, and document it all really well.

I hope "distro developers" will include folk like Open Embedded developers
rather than just targetting the Red Hat's, Debians and SuSE's ?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core

Mike Bell

unread,
Jun 27, 2005, 3:30:19 AM6/27/05
to
On Sat, Jun 25, 2005 at 04:43:05PM -0700, Greg KH wrote:
> So no, I'm not going to be submitting this. But what it is, is a nice
> proof-of-concept for people who "just can't live without a in-kernel
> devfs" to show that it can be done in less than 300 lines of code, and
> only 6 hooks (2 functions in 3 different places) in the main kernel
> tree. That is managable outside of the main kernel for years, with
> almost little to no effort.

Except that it isn't.

The "everything in the root" model just doesn't seem to work. It's been
so long since I used linux without devfs I hadn't thought about how
things like ALSA and the input subsystem have gone beyond supporting
device nodes in a subdirectory to actually requiring device nodes to be
in a subdirectory.

The obvious (and less important) legacy stuff has the old standard
names, but for the newer, properly named stuff like the input subsystem
and ALSA, it's just yet another incompatible naming scheme, and this one
doesn't even have the advantage of being an improvement in /dev
cleanliness like devfs tried to be.

For it to be manageable outside the mainline kernel the device names
/have/ to be inside the mainline kernel and have to be something
applications recognise without patching. When the ones in sysfs don't
work, we're back to needing the ones drivers provide through devfs
hooks, since I somehow don't see you modifying sysfs to accommodate a
project like this. :)

It's a shame too, once I had symlink, mkdir, mknod, chown/chmod and
unlink of symlinks working on the filesystem I was able to boot up with
it as /dev on my laptop, and figured it would just be a matter of
de-devfsifying my scripts, but it looks now like the names it implements
are just plain unworkable rather than merely inconvenient, quite aside
from the unholy amount of pointless chmoding required.

What could work is using the devfs-style registration hooks with a
filesystem like this, but that returns us to what I proposed (and I
believe a few people before me actually have coded up) of a simply
cleaned up and simplified devfs. Which, as far as I know, you outright
reject.

Adam J. Richter

unread,
Jun 27, 2005, 12:00:23 PM6/27/05
to
On 2005-06-24, Greg KH wrote:
>Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
>tiny:
>$ size fs/ndevfs/inode.o
> text data bss dec hex filename
> 1571 200 8 1779 6f3 fs/ndevfs/inode.o
>replacement for devfs for those embedded users who just can't live
>without the damm thing. It doesn't allow subdirectories, and only uses
>LSB compliant names. But it works, and should be enough for people to
>use, if they just can't wean themselves off of the idea of an in-kernel
>fs to provide device nodes.
>
>Now, with this, is there still anyone out there who just can't live
>without devfs in their kernel?
>
>Damm, the depths I've sunk to these days, I'm such a people pleaser...
>
>Comments? Questions? Criticisms?

This file system is not a replacement for devfs.

In an email that Andrew Morton sent to me in November 2004
about my small replacement devfs (which, ulike ndevfs _is_ actually a
serious development path for devfs), he essentially set a rather high
criterion for integrating a replacement. "Either we make this
thing 110% compatible with existing userland or we hold off for 2.7.x."
ndevfs should be subject to the same standard or, preferably, the
standard should be relaxed for both devfs-like projects, as I think
it doesn't benefit devfs users or anyone else to be so stringent.

Also, I'm sure this was just an oversight, but you ought
to post your proposed file system to linux-fsdevel. I think some
people who care about file system particularly might watch that
list more carefully than lkml.

To avoid arguing by unsupported assertion, I'll explain why
I believe ndevfs is not a replacement for devfs, even if it seems a
bit obvious.

To start with the most obvious, subdirectories in /dev is
something many people find to be a much more readable user interface
(which can save human time and avoid mistakes, which is often the whole
point of computers).

Perhaps less obvious, ndevfs system lacks demand-loading
functionality, which will typically make your system consume _more_
memory than a system using either the old devfs or my lookup trapping
facility that I separated from my devfs variant. With demand loading,
it is not necessary to load modules for sound interfaces, or devices
that are available but will not be used before the computer shuts down,
or even to spin up disks to scan partition tables that will not be used.
It can also be useful to be able to create soft devices on demand that
have no hardware counterpart, especially in /dev/mapper/.

If this file system gets integrated and my devfs implementation
does not, it will a send a message to contributors about personal
favoritism over technical merit, especially when I previously set a
public example by agreeing to hold off on integration until after 2.6.

I want to be clear that I would not mind seeing ndevfs
integrated as an _additional_ file system that people could use as
an alternative to devfs, but if that is done, I think other more
meritorious file system should be get integrated as well, including
the devfs that I made (I'm happy to see old devfs continue to be
available too).

Currently, I think it is not too strong a term to say
that devfs in the stock kernel tree is being sabotaged, when substantial
improvements are refused integration on the basis of artificially
high compatability standards not requested by its user community and
with some of the most non-objective--no that's not clear enough,
"BS"--technical claims are added to official documentation in places
like fs/Kconfig ("note that devfs has been obseleted by udev....only
provided for legacy installations...unfortunately different from the
names normal Linux installations use").

Andrew, before you integrate ndevfs, you should integrate the
devfs variant that I made too. I say this not because I feel that I've
been treated a bit unfairly (although I'm obviously being quite candid
that I do feel that way about this matter), but because Linux will be
better off if the ability to do things that devfs allows is more widely
available both because of potential memory savings and because better
user interfaces often really do make a particular software system
(such as Linux) the better solution (e.g., being able to do "ls /dev/discs"
to see how many disk-like devices the kernel already sees).

__ ______________
Adam J. Richter \ /
ad...@yggdrasil.com | g g d r a s i l

Dmitry Torokhov

unread,
Jun 27, 2005, 6:40:13 PM6/27/05
to
On Monday 27 June 2005 02:19, Mike Bell wrote:
> On Sat, Jun 25, 2005 at 04:43:05PM -0700, Greg KH wrote:
> > So no, I'm not going to be submitting this. But what it is, is a nice
> > proof-of-concept for people who "just can't live without a in-kernel
> > devfs" to show that it can be done in less than 300 lines of code, and
> > only 6 hooks (2 functions in 3 different places) in the main kernel
> > tree. That is managable outside of the main kernel for years, with
> > almost little to no effort.
>
> Except that it isn't.
>
> The "everything in the root" model just doesn't seem to work. It's been
> so long since I used linux without devfs I hadn't thought about how
> things like ALSA and the input subsystem have gone beyond supporting
> device nodes in a subdirectory to actually requiring device nodes to be
> in a subdirectory.

AFAIK there is no requirement in input subsystem that devices should be
created under /dev/input. When devfs is activated they are created there
by default, but that's it.

--
Dmitry

J.A. Magallon

unread,
Jun 27, 2005, 7:50:06 PM6/27/05
to
Hi...

I will post in this dicussion, even I'm not aware of any
techical/religious concerns with devfs, udev and co.
I just want to give a suer/admin point of view.
Flame-proof suit goes on...

On 06.27, Adam J. Richter wrote:
> On 2005-06-24, Greg KH wrote:
> >Anyway, here's yet-another-ramfs-based filesystem, ndevfs. It's a very
> >tiny:
> >$ size fs/ndevfs/inode.o
> > text data bss dec hex filename
> > 1571 200 8 1779 6f3 fs/ndevfs/inode.o
> >replacement for devfs for those embedded users who just can't live
> >without the damm thing. It doesn't allow subdirectories, and only uses
> >LSB compliant names. But it works, and should be enough for people to
> >use, if they just can't wean themselves off of the idea of an in-kernel
> >fs to provide device nodes.
> >
> >Now, with this, is there still anyone out there who just can't live
> >without devfs in their kernel?
> >
> >Damm, the depths I've sunk to these days, I'm such a people pleaser...
> >
> >Comments? Questions? Criticisms?
>

...


>
> To start with the most obvious, subdirectories in /dev is
> something many people find to be a much more readable user interface
> (which can save human time and avoid mistakes, which is often the whole
> point of computers).
>

I agree on this.

> Perhaps less obvious, ndevfs system lacks demand-loading
> functionality, which will typically make your system consume _more_
> memory than a system using either the old devfs or my lookup trapping
> facility that I separated from my devfs variant. With demand loading,
> it is not necessary to load modules for sound interfaces, or devices
> that are available but will not be used before the computer shuts down,
> or even to spin up disks to scan partition tables that will not be used.
> It can also be useful to be able to create soft devices on demand that
> have no hardware counterpart, especially in /dev/mapper/.
>

What I would like (I know the answer will be 'write it', but anyways...)

- Boot with an empty /dev. Especially for diskless nodes on clusters
- Mount a filesystem on /dev that shows the registered drivers _at the
moment of mount action_. No need to magically show devices afterwards.
Let rc mount it as the very first thing it does. Or even it could
be mounted in kernel just before calling init, to allow booting
with init=/bin/bash and have a console...
- That filesystem should allow all normal ops (mkdir, ln -s, chmod ...)
to let udev do its work after init starts.
- Let devices appear on /sys, and let userspace decide if it wants the
device created or not and where.

No magical load of drivers if I access a non existent device node. What
for ? I want the node when device is there, not when somebody tries to
open it. I want the device when the user plugs its firewire drive, not
when he tries to open it and forgot to plug it.

What about devices present but not used ? Is it so big the overload in
memory that an embedded system will have ? Sure you can shave many more
bytes in userspace...
What if I don't want to see sound devices even if I have the hardware ?
Write the right init scripts sequence. Nowadays distros use udev, but
just start udev and let it create everything. All it finds under /sys.
You could split current udev
in each subsytem, and make the sound initscript to do something like
'udevstart SOUND' (don't remember the exact syntax) to create the
sound device nodes (forced hotplugging ?). If you don't start sound,
no sound devices. With a fully configured udev/hotplug system, perhaps
initscripts could reduce to 'udevstart XXXX'...

I am surely missing too many techical details, but this is what I would
really like to see from a user point of view.

Is it so difficult to get an agreement ?


--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586

Linux 2.6.12-jam4 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

Mike Bell

unread,
Jun 27, 2005, 7:50:04 PM6/27/05
to
On Mon, Jun 27, 2005 at 05:35:50PM -0500, Dmitry Torokhov wrote:
> AFAIK there is no requirement in input subsystem that devices should be
> created under /dev/input. When devfs is activated they are created there
> by default, but that's it.

Things which accept a path to an event file as an argument will work
just fine. But anything which tries autodiscovery HAS to be able to find
the device nodes. Think directfb, most (but not all) of the X patches,
any user-space driver that wants to find the hardware it owns, etc.

This illustrates nicely my reasons for preferring devfs.

1) Predictable, canonical device names are a Good Thing.

2) If you accept that, exporting the device names from the kernel is the
most sensible way to do it.

For point one, how do you do autodiscovery otherwise? You can look at
sysfs or /proc/bus/input/devices to find out what input devices are on
the system, but if the device nodes can be named anything then how do
you find them? Grep over all of /dev and find the guy with the right
major/minor? Or create your own private device node using the dev sysfs
parameter? Or use some crazy interface to udev's configuration files to
find out what the hell it decided to name the node?

For point two, without doubting the need for a userspace utility to do
chown and symlinks to meaningful names, I cannot conceive of how anyone
could say "I need a device node named /dev/input/event0 with this
major/minor created and deleted according to in-kernel events. The best
way to do this is to export an empty ram-backed filesystem and mount it
on /dev from userspace, use a second kernel-generated filesystem to
export a file called /sys/class/input/event0/dev with the major and
minor in it, use a second kernel->userspace interface to send an event
to a userspace helper which will read that value, look up that it's
supposed to be named /dev/input/event0, and mknod the corresponding
device file". Not if the node is always going to be named
/dev/input/event0.

udev can do lots of amazing things, but ONE of the things it does,
creating device nodes, could be done much better in the kernel IMHO. The
only thing udev offers over a devfs-like solution in this regard is the
ability to have those device nodes use all sorts of wacky, random names.
And that's not a feature in my book, it's a colossal bug. If you want
wacky, random names, make them symlinks. And please don't confuse hatred
for ide/host0/bus0/target0/lun0/part1 versus hda1 with hatred of
standardized names. Picking a dumb standard one time doesn't mean
standards are dumb.

Greg KH

unread,
Jun 28, 2005, 12:00:12 AM6/28/05
to
On Mon, Jun 27, 2005 at 08:19:19AM +0200, Arnd Bergmann wrote:
> On Freedag 24 Juni 2005 10:18, Greg KH wrote:
> > +
> > +??????????????list_for_each_entry(entry, &entries, node) {
> > +??????????????????????????????if (strcmp(name, &entry->name[0]) == 0) {
> > +??????????????????????????????????????????????dentry = entry->dentry;
> > +??????????????????????????????????????????????break;
> > +??????????????????????????????}
> > +??????????????}
>
> This list search looks like it is missing a mutex around it,

Yes.

> and the elements of the list never get freed properly.

Yeah, I noticed that after I posted it.

I was at the end of my self-imposed, "I'm only giving myself 3 hours for
this", and didn't want to touch it anymore :)

> Is it possible to use lookup_one_len() instead? That should
> make it possible not to use an extra list of entries at all.

Yeah, I originally tried a different function from namei.c, but getting
the mount point was a bit messy at the moment.

I'll take some time later this week and fix this up and post it one more
time for anyone else to use.

But remember, I'll be posting it, and not asking for it to be accepted,
as I was wrong. devfs is not needed, it's wrong, and will be removed
from the kernel. But more about that later...

thanks,

greg k-h

Greg KH

unread,
Jun 28, 2005, 12:00:13 AM6/28/05
to
On Sun, Jun 26, 2005 at 09:23:20AM +0100, Russell King wrote:
> On Sat, Jun 25, 2005 at 04:43:05PM -0700, Greg KH wrote:
> > > What we really need is a short HOWTO that covers:
> > >
> > > - Do you really need a dynamic /dev?
> > > - How to embed a static /dev in your embedded kernel with initramfs
> > > - How to add a dynamic /dev to your kernel with udev
> >
> > Yes, I'm going to start working with some of the people who really know
> > this stuff (the distro developers who make the whole dynamic boot and
> > early boot process work correctly) and we will hash out a coheirant
> > future together, and document it all really well.
>
> I hope "distro developers" will include folk like Open Embedded developers
> rather than just targetting the Red Hat's, Debians and SuSE's ?

Of course, if there are any people you can think of that I should
contact about this, in the embedded world, please give me their
names/email addresses (offlist if you wish.)

thanks,

greg k-h

Greg KH

unread,
Jun 28, 2005, 4:40:18 AM6/28/05
to
On Mon, Jun 27, 2005 at 04:26:00PM -0700, Mike Bell wrote:
> On Mon, Jun 27, 2005 at 05:35:50PM -0500, Dmitry Torokhov wrote:
> > AFAIK there is no requirement in input subsystem that devices should be
> > created under /dev/input. When devfs is activated they are created there
> > by default, but that's it.
>
> Things which accept a path to an event file as an argument will work
> just fine. But anything which tries autodiscovery HAS to be able to find
> the device nodes. Think directfb, most (but not all) of the X patches,
> any user-space driver that wants to find the hardware it owns, etc.
>
> This illustrates nicely my reasons for preferring devfs.
>
> 1) Predictable, canonical device names are a Good Thing.

And impossible for the kernel to generate given hotpluggable devices.

> 2) If you accept that, exporting the device names from the kernel is the
> most sensible way to do it.

I don't accept it, and neither does anyone else. See my previous posts
about devfs and udev for more details, I'm not going to go into this
again...

Good luck,

greg k-h

Greg KH

unread,
Jun 28, 2005, 4:40:23 AM6/28/05
to
On Fri, Jun 24, 2005 at 08:57:55PM -0400, Kyle Moffett wrote:
> One of the things that most annoys me about udev is that I still need
> a minimal static dev in order for the system to boot.

Why? You should not. Works just fine for me here :)

I suggest you work on your init scripts some more...

greg k-h

Greg KH

unread,
Jun 28, 2005, 5:00:21 AM6/28/05
to
On Fri, Jun 24, 2005 at 12:10:53PM -0500, Bill Gatliff wrote:
>
> I moved your Kconfig diff; it was showing up in miscellaneous
> filesystems, I put it in pseudo filesystems instead.

Ah, thanks, that's a better place for it.