[ANNOUNCE] ndevfs - a "nano" devfs

[Greg KH]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[Mike Bell]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[Mike Bell]

On Tue, Jun 28, 2005 at 12:40:15AM -0700, Greg KH wrote:
> > 1) Predictable, canonical device names are a Good Thing.
>
> And impossible for the kernel to generate given hotpluggable devices.

Bull. It's clear I'm talking about per-subsystem, not having individual
devices show up with the same name each time. Or are you suggesting that
hotplug might somehow turn my keyboard into a hard drive?

> I don't accept it, and neither does anyone else.

So then explain this to me, I've got a GUI sound player, on first
invocation it displays a list of sound cards installed on the system,
allows the user to select one, and then plays the sound file. How is it
supposed to do that if the device nodes for sound card 0 could be named
anything? I can get a list of sound cards from /proc/asound or
/sys/class/sound, but unless the sound card device nodes are predictably
named there's no way to find them short of searching every node in /dev.

[Arjan van de Ven]

On Tue, 2005-06-28 at 02:08 -0700, Mike Bell wrote:
> On Tue, Jun 28, 2005 at 12:40:15AM -0700, Greg KH wrote:
> > > 1) Predictable, canonical device names are a Good Thing.
> >
> > And impossible for the kernel to generate given hotpluggable devices.
>
> Bull. It's clear I'm talking about per-subsystem, not having individual
> devices show up with the same name each time.

you still can't have that. think USB harddisks for example. The only way
you can do this reliable is to use UUIDs from the disks. Guess what..
udev does that. devfs doesn't.

Same for PCI hotplug; the "path" to your pci IDE controller might change
after you "hotplugged" some stuff. And no that's not just high end
hardware; most docking stations are like this too. Again, only the disk
UUID is usable for getting stable naming.

> > I don't accept it, and neither does anyone else.
>
> So then explain this to me, I've got a GUI sound player, on first
> invocation it displays a list of sound cards installed on the system,
> allows the user to select one, and then plays the sound file. How is it
> supposed to do that if the device nodes for sound card 0 could be named
> anything? I can get a list of sound cards from /proc/asound or
> /sys/class/sound, but unless the sound card device nodes are predictably
> named there's no way to find them short of searching every node in /dev.

actually.. linphone for example shows you the name of the device, not
the device node. And at runtime it finds which device node belongs to
that name somehow. I didn't look at the code how it does that, but it
sure isn't impossible since it's done in practice already.

[Mike Bell]

On Tue, Jun 28, 2005 at 11:21:27AM +0200, Arjan van de Ven wrote:
> you still can't have that. think USB harddisks for example. The only way
> you can do this reliable is to use UUIDs from the disks. Guess what..
> udev does that. devfs doesn't.

I thought I had made it clear that I wasn't talking about uniquely
identifying a given piece of hardware, that can only be done in
userspace (and often not even there).

What I'm talking about is the ability to find the device node that
corresponds to the first entry in /proc/bus/input/devices, or play a
sound file on the system's first sound card, or for X to find the drm
device node that corresponds to a given video card. All these things are
easy if you know that /dev/input/event0 is the device node for the first
entry, but if that device node could be called /dev/myfunkykeyboard
(note, the device name, you could still have a symlink to said name if
you wanted without breaking anything), in a world where udev's
supposed feature of allowing devices to be named anything you want is
actually used, this isn't possible without scanning all of /dev.

> actually.. linphone for example shows you the name of the device, not
> the device node. And at runtime it finds which device node belongs to
> that name somehow. I didn't look at the code how it does that, but it
> sure isn't impossible since it's done in practice already.

It is impossible though, if you make use of that particular feature of
udev. Give it a try, move all your alsa device nodes to other names and
see how completely unusable ALSA becomes. Those device nodes HAVE to
exist and HAVE to point to the right devices in order for ALSA to work.

linphone and other programs "just work" because they know where to find
their device nodes. If anything, you're arguing my point.

[Oliver Neukum]

Am Dienstag, 28. Juni 2005 09:40 schrieb Greg KH:
> 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.

That is not true. The kernel can generate predictable device names.
It just cannot generate _stable_ device names under all circumstances.

Regards
Oliver

[Tom Rini]

On Tue, Jun 28, 2005 at 12:41:45AM -0700, Greg KH wrote:
> 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 :)

Er, don't you need /dev/console for console output to happen? (And that
it's a good idea to have /dev/null around too). Or has that changed?

--
Tom Rini
http://gate.crashing.org/~trini/

[Olaf Hering]

On Tue, Jun 28, Tom Rini wrote:

> On Tue, Jun 28, 2005 at 12:41:45AM -0700, Greg KH wrote:
> > 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 :)
>
> Er, don't you need /dev/console for console output to happen? (And that
> it's a good idea to have /dev/null around too). Or has that changed?

scripts/gen_initramfs_list.sh creates that for every kernel.

[Tom Rini]

On Tue, Jun 28, 2005 at 11:08:04PM +0200, Olaf Hering wrote:
> On Tue, Jun 28, Tom Rini wrote:
>
> > On Tue, Jun 28, 2005 at 12:41:45AM -0700, Greg KH wrote:
> > > 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 :)
> >
> > Er, don't you need /dev/console for console output to happen? (And that
> > it's a good idea to have /dev/null around too). Or has that changed?
>
> scripts/gen_initramfs_list.sh creates that for every kernel.

I get "Warning: unable to open initial console", so on post 2.6.12 (but
now stale) git. Does userspace need to be doing something as well?

--
Tom Rini
http://gate.crashing.org/~trini/

[Jim Crilly]

On 06/28/05 11:21:27AM +0200, Arjan van de Ven wrote:
> >
> > So then explain this to me, I've got a GUI sound player, on first
> > invocation it displays a list of sound cards installed on the system,
> > allows the user to select one, and then plays the sound file. How is it
> > supposed to do that if the device nodes for sound card 0 could be named
> > anything? I can get a list of sound cards from /proc/asound or
> > /sys/class/sound, but unless the sound card device nodes are predictably
> > named there's no way to find them short of searching every node in /dev.
>
>
> actually.. linphone for example shows you the name of the device, not
> the device node. And at runtime it finds which device node belongs to
> that name somehow. I didn't look at the code how it does that, but it
> sure isn't impossible since it's done in practice already.

I took a quick look and for OSS devices linphone seems to just loop over
/dev/dsp* so if the names were moved, I doubt it would work.

But it also seems to have ALSA support and in that case it uses
snd_card_get_name in a for loop to build a list of available cards, since
all ALSA functions use card index numbers they should work fine independent
of device file names.

Jim.

[Michael Tokarev]

Tom Rini wrote:
> On Tue, Jun 28, 2005 at 11:08:04PM +0200, Olaf Hering wrote:

[]

>>>Er, don't you need /dev/console for console output to happen? (And that
>>>it's a good idea to have /dev/null around too). Or has that changed?
>>
>>scripts/gen_initramfs_list.sh creates that for every kernel.
>
> I get "Warning: unable to open initial console", so on post 2.6.12 (but
> now stale) git. Does userspace need to be doing something as well?

Are you using initramfs (cpio archive of the root fs)?
Or "ol'good" initrd (cramfs, romfs, whatever)?

/mjt

[Tom Rini]

On Wed, Jun 29, 2005 at 02:08:41AM +0400, Michael Tokarev wrote:
> Tom Rini wrote:
> >On Tue, Jun 28, 2005 at 11:08:04PM +0200, Olaf Hering wrote:
> []
> >>>Er, don't you need /dev/console for console output to happen? (And that
> >>>it's a good idea to have /dev/null around too). Or has that changed?
> >>
> >>scripts/gen_initramfs_list.sh creates that for every kernel.
> >
> >I get "Warning: unable to open initial console", so on post 2.6.12 (but
> >now stale) git. Does userspace need to be doing something as well?
>
> Are you using initramfs (cpio archive of the root fs)?
> Or "ol'good" initrd (cramfs, romfs, whatever)?

I'm just booting the kernel as normal, and assuming that the initramfs
that's built by default is used before my real rootfs happens.

--
Tom Rini
http://gate.crashing.org/~trini/

[Mike Bell]

On Tue, Jun 28, 2005 at 05:49:29PM -0400, Jim Crilly wrote:
> I took a quick look and for OSS devices linphone seems to just loop over
> /dev/dsp* so if the names were moved, I doubt it would work.
>
> But it also seems to have ALSA support and in that case it uses
> snd_card_get_name in a for loop to build a list of available cards, since
> all ALSA functions use card index numbers they should work fine independent
> of device file names.

No, they shouldn't. Try it and see. Yes, your /program/ uses the sound
card index, but that's because the ALSA library internally assumes that
sound card index 0 corresponds to certain device nodes.

Eventually every program has to be able to find the device node. That's
just obvious, if you don't need the device node why have it in the first
place? And if it can't predict what that device node will be named, the
only thing it can do (short of creating its own private device node,
which breaks all sorts of stuff /and/ is dumb /and/ doesn't work unless
you're root) is search over every single device node in /dev to find the
one with the correct major/minor. Or ask the user to type it in
manually, which is all well and good for maybe an admin configuring some
system, but is completely broken for anything GUI or automatic.

Hence my conclusion, predictable device file names are a requirement.
udev's "name the device whatever you want" works fine for running vi on
/etc/fstab, but when you want a program to do anything intelligent like
present a list of available choices, you need to be able to find the
device node.

[Greg KH]

On Tue, Jun 28, 2005 at 02:00:08PM +0200, Oliver Neukum wrote:
> Am Dienstag, 28. Juni 2005 09:40 schrieb Greg KH:
> > 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.
>
> That is not true. The kernel can generate predictable device names.
> It just cannot generate _stable_ device names under all circumstances.

Well, I view "canonical" as, "this is the name for this specific device,
and will always be that name". But, if others think of it differently,
hey, that's fine with me too.

And yes, I also agree with your statement.

thanks,

greg k-h

[Jim Crilly]

On 06/28/05 03:23:18PM -0700, Mike Bell wrote:
> On Tue, Jun 28, 2005 at 05:49:29PM -0400, Jim Crilly wrote:
> > I took a quick look and for OSS devices linphone seems to just loop over
> > /dev/dsp* so if the names were moved, I doubt it would work.
> >
> > But it also seems to have ALSA support and in that case it uses
> > snd_card_get_name in a for loop to build a list of available cards, since
> > all ALSA functions use card index numbers they should work fine independent
> > of device file names.
>
> No, they shouldn't. Try it and see. Yes, your /program/ uses the sound
> card index, but that's because the ALSA library internally assumes that
> sound card index 0 corresponds to certain device nodes.

I stand corrected then. I didn't actually try anything with linphone, the
ALSA API just makes it look like the device nodes don't matter.

>
> Eventually every program has to be able to find the device node. That's
> just obvious, if you don't need the device node why have it in the first
> place? And if it can't predict what that device node will be named, the
> only thing it can do (short of creating its own private device node,
> which breaks all sorts of stuff /and/ is dumb /and/ doesn't work unless
> you're root) is search over every single device node in /dev to find the
> one with the correct major/minor. Or ask the user to type it in
> manually, which is all well and good for maybe an admin configuring some
> system, but is completely broken for anything GUI or automatic.
>
> Hence my conclusion, predictable device file names are a requirement.
> udev's "name the device whatever you want" works fine for running vi on
> /etc/fstab, but when you want a program to do anything intelligent like
> present a list of available choices, you need to be able to find the
> device node.

Well it looks like the ALSA library already abstracts the device node
enough that the app itself doesn't know what file is being used because it
just calls snd_card_get_name, snd_open_pcm, etc with the ALSA index. So
wouldn't it be feasible to make ALSA a little bit smarter so that it could
track/find the device nodes no matter what name they have? I'm not
advocating for or against it, but from my cursory look at the API it looks
possible to do without breaking any ALSA apps.

Jim.

[Mike Bell]

On Tue, Jun 28, 2005 at 07:43:10PM -0400, Jim Crilly wrote:
> Well it looks like the ALSA library already abstracts the device node
> enough that the app itself doesn't know what file is being used because it
> just calls snd_card_get_name, snd_open_pcm, etc with the ALSA index. So
> wouldn't it be feasible to make ALSA a little bit smarter so that it could
> track/find the device nodes no matter what name they have?

You could in theory do that to ALSA. Except for the aforementioned
"how?". How is ALSA supposed to find out what its new device node name
is? You could invent some sort of crazy libudev, but I think it would
require a major redesign of how udev works, forcing it to keep state or
such. The only alternatives I can see are what I already mentioned,
searching every single device node in /dev to find the right one.

Which is why I conclude (and, evidently, Greg agrees) that consistent
naming schemes for /dev are very important. Now if I could just find out
why devfs's failure to allow such broken configurations is a bug in his
mind. :)

[Mike Bell]

On Tue, Jun 28, 2005 at 05:39:16PM -0700, David Lang wrote:
> worse yet, go way back in the archives and you will find that prior to
> being merged into the kernel devfs supported two nameing schemes, the one
> you see now and a compatability version that matched the standard /dev
> names. one requirement for allowing it to be merged was to remove the
> compatability set of names.

Yes, I vaguely remember. IIRC Linus was the one who mandated the use of
a directory based structure before devfs would be merged, though I think
the particular choice of names was not his fault.

Which is why I've asked people to seperate their distaste for the names
devfs uses from distaste for having a standard set of names.

Originally I was hoping that all those plans to move partition detection
into userspace using device-mapper would help eliminate people's
objections to devfs (AFAIK the devfs-style names hated most by far are
block devices, which are way too long), but it didn't work out that way.

[David Lang]

On Tue, 28 Jun 2005, Mike Bell wrote:

> On Tue, Jun 28, 2005 at 07:43:10PM -0400, Jim Crilly wrote:
>> Well it looks like the ALSA library already abstracts the device node
>> enough that the app itself doesn't know what file is being used because it
>> just calls snd_card_get_name, snd_open_pcm, etc with the ALSA index. So
>> wouldn't it be feasible to make ALSA a little bit smarter so that it could
>> track/find the device nodes no matter what name they have?
>
> You could in theory do that to ALSA. Except for the aforementioned
> "how?". How is ALSA supposed to find out what its new device node name
> is? You could invent some sort of crazy libudev, but I think it would
> require a major redesign of how udev works, forcing it to keep state or
> such. The only alternatives I can see are what I already mentioned,
> searching every single device node in /dev to find the right one.
>
> Which is why I conclude (and, evidently, Greg agrees) that consistent
> naming schemes for /dev are very important. Now if I could just find out
> why devfs's failure to allow such broken configurations is a bug in his
> mind. :)

worse yet, go way back in the archives and you will find that prior to

being merged into the kernel devfs supported two nameing schemes, the one
you see now and a compatability version that matched the standard /dev
names. one requirement for allowing it to be merged was to remove the
compatability set of names.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare

[Oliver Neukum]

Am Dienstag, 28. Juni 2005 22:08 schrieben Sie:

> On Tue, Jun 28, 2005 at 02:00:08PM +0200, Oliver Neukum wrote:
> > Am Dienstag, 28. Juni 2005 09:40 schrieb Greg KH:
> > > 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.
> >
> > That is not true. The kernel can generate predictable device names.
> > It just cannot generate _stable_ device names under all circumstances.
>
> Well, I view "canonical" as, "this is the name for this specific device,
> and will always be that name". But, if others think of it differently,
> hey, that's fine with me too.

Isn't the canonical way to use canonical to mean a name that is independent
of a particular system but set in a standard? Such a name could be generated
only if the device itself is unique. Short of network cards and
bluetooth devices you'll be short on canonical, stable names.

In other cases you have heuristics and system configuration. These are nice
to have, but have limits and problems. Firstly, they are heuristics and thus
a bit risky to use. Secondly, they sometimes need system configuration.
And this very much limits usefullness to embedded and indeed single user
systems.

What devfs and udev can do, and a static dev cannot, is names independent
of order of detection. As for ressources, it is an illusion to think that user
space means less ressources. A demon means page tables and a kernel
stack. That 12K unswappable memory in the best case.

Regards
Oliver

[Greg KH]

On Wed, Jun 29, 2005 at 08:41:29AM +0200, Oliver Neukum wrote:
> What devfs and udev can do, and a static dev cannot, is names independent
> of order of detection.

devfs can not do that.

> As for ressources, it is an illusion to think that user space means
> less ressources. A demon means page tables and a kernel stack. That
> 12K unswappable memory in the best case.

You don't have to run the udevd process if you are worried about an
extra process in your kernel tables. Although this is the first time I
have heard anyone voice the "oh no, not another userspace task running"
point :)

thanks,

greg k-h

[Oliver Neukum]

Am Mittwoch, 29. Juni 2005 18:06 schrieben Sie:

> On Wed, Jun 29, 2005 at 08:41:29AM +0200, Oliver Neukum wrote:
> > What devfs and udev can do, and a static dev cannot, is names independent
> > of order of detection.
>
> devfs can not do that.

Why not?

> > As for ressources, it is an illusion to think that user space means
> > less ressources. A demon means page tables and a kernel stack. That
> > 12K unswappable memory in the best case.
>
> You don't have to run the udevd process if you are worried about an

What about events arriving out of order?

> extra process in your kernel tables. Although this is the first time I
> have heard anyone voice the "oh no, not another userspace task running"
> point :)

Well, you should have. 16K is a more realistic figure. Tasks have their cost.
In fact:
root 1 0.0 0.0 684 248 ? S 16:58 0:01 init [5]
root 2 0.0 0.0 0 0 ? SN 16:58 0:00 [ksoftirqd/0]
root 3 0.0 0.0 0 0 ? S< 16:58 0:00 [events/0]
root 4 0.0 0.0 0 0 ? S< 16:58 0:00 [khelper]
root 5 0.0 0.0 0 0 ? S< 16:58 0:00 [kthread]
<snip>
root 3424 0.0 0.1 2032 632 tty3 Ss+ 16:59 0:00 /sbin/mingetty tty3
root 3425 0.0 0.1 2032 632 tty4 Ss+ 16:59 0:00 /sbin/mingetty tty4
root 3426 0.0 0.1 2032 632 tty5 Ss+ 16:59 0:00 /sbin/mingetty tty5
root 3427 0.0 0.1 2032 632 tty6 Ss+ 16:59 0:00 /sbin/mingetty tty6

Counting this I arrive at 51*16K = 816K. That's a whole lot of unswappable
memory. Thinking user space cheap is an automatic reflex these days. It's
sometimes misleading like all blind reflexes.
It makes me feel a fool for caring about __init and __exit.

Regards
Oliver