[PATCH] devfs: Remove devfs from the partition code

Greg KH

unread,

Jun 21, 2005, 3:58:20 AM6/21/05

to linux-...@vger.kernel.org, gre...@suse.de

This patch removes the devfs code from the fs/partitions/ directory.

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

---
commit 7780cade30d7fb5b9bebb67ccd5bb76f9a28fb23
tree 1484299b0a29203df4c9654eaff9197589247f5b
parent 7b9a41ff4e1a04c605f117cf1ee4e89c96be5c12
author Greg Kroah-Hartman <gre...@suse.de> Mon, 20 Jun 2005 21:15:16 -0700
committer Greg Kroah-Hartman <gre...@suse.de> Mon, 20 Jun 2005 23:13:30 -0700

fs/partitions/Makefile | 1
fs/partitions/check.c | 26 ++--------
fs/partitions/devfs.c | 130 ------------------------------------------------
fs/partitions/devfs.h | 10 ----
4 files changed, 5 insertions(+), 162 deletions(-)

diff --git a/fs/partitions/Makefile b/fs/partitions/Makefile
--- a/fs/partitions/Makefile
+++ b/fs/partitions/Makefile
@@ -4,7 +4,6 @@

obj-y := check.o

-obj-$(CONFIG_DEVFS_FS) += devfs.o
obj-$(CONFIG_ACORN_PARTITION) += acorn.o
obj-$(CONFIG_AMIGA_PARTITION) += amiga.o
obj-$(CONFIG_ATARI_PARTITION) += atari.o
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -21,7 +21,6 @@
#include <linux/devfs_fs_kernel.h>

#include "check.h"
-#include "devfs.h"

#include "acorn.h"
#include "amiga.h"
@@ -160,18 +159,11 @@ check_partition(struct gendisk *hd, stru
if (!state)
return NULL;

-#ifdef CONFIG_DEVFS_FS
- if (hd->devfs_name[0] != '\0') {
- printk(KERN_INFO " /dev/%s:", hd->devfs_name);
+ disk_name(hd, 0, state->name);
+ printk(KERN_INFO " %s:", state->name);
+ if (isdigit(state->name[strlen(state->name)-1]))
sprintf(state->name, "p");
- }
-#endif
- else {
- disk_name(hd, 0, state->name);
- printk(KERN_INFO " %s:", state->name);
- if (isdigit(state->name[strlen(state->name)-1]))
- sprintf(state->name, "p");
- }
+
state->limit = hd->minors;
i = res = 0;
while (!res && check_part[i]) {
@@ -340,14 +332,8 @@ void register_disk(struct gendisk *disk)
kobject_hotplug(&disk->kobj, KOBJ_ADD);

/* No minors to use for partitions */
- if (disk->minors == 1) {
- if (disk->devfs_name[0] != '\0')
- devfs_add_disk(disk);
+ if (disk->minors == 1)
return;
- }
-
- /* always add handle for the whole disk */
- devfs_add_partitioned(disk);

/* No such device (e.g., media were just removed) */
if (!get_capacity(disk))
@@ -435,8 +421,6 @@ void del_gendisk(struct gendisk *disk)
disk_stat_set_all(disk, 0);
disk->stamp = disk->stamp_idle = 0;

- devfs_remove_disk(disk);
-
if (disk->driverfs_dev) {
sysfs_remove_link(&disk->kobj, "device");
sysfs_remove_link(&disk->driverfs_dev->kobj, "block");
diff --git a/fs/partitions/devfs.c b/fs/partitions/devfs.c
deleted file mode 100644
--- a/fs/partitions/devfs.c
+++ /dev/null
@@ -1,130 +0,0 @@
-/*
- * This tries to keep block devices away from devfs as much as possible.
- */
-#include <linux/fs.h>
-#include <linux/devfs_fs_kernel.h>
-#include <linux/vmalloc.h>
-#include <linux/genhd.h>
-#include <linux/bitops.h>
-#include <asm/semaphore.h>
-
-
-struct unique_numspace {
- u32 num_free; /* Num free in bits */
- u32 length; /* Array length in bytes */
- unsigned long *bits;
- struct semaphore mutex;
-};
-
-static DECLARE_MUTEX(numspace_mutex);
-
-static int expand_numspace(struct unique_numspace *s)
-{
- u32 length;
- void *bits;
-
- if (s->length < 16)
- length = 16;
- else
- length = s->length << 1;
-
- bits = vmalloc(length);
- if (!bits)
- return -ENOMEM;
- if (s->bits) {
- memcpy(bits, s->bits, s->length);
- vfree(s->bits);
- }
-
- s->num_free = (length - s->length) << 3;
- s->bits = bits;
- memset(bits + s->length, 0, length - s->length);
- s->length = length;
-
- return 0;
-}
-
-static int alloc_unique_number(struct unique_numspace *s)
-{
- int rval = 0;
-
- down(&numspace_mutex);
- if (s->num_free < 1)
- rval = expand_numspace(s);
- if (!rval) {
- rval = find_first_zero_bit(s->bits, s->length << 3);
- --s->num_free;
- __set_bit(rval, s->bits);
- }
- up(&numspace_mutex);
-
- return rval;
-}
-
-static void dealloc_unique_number(struct unique_numspace *s, int number)
-{
- int old_val;
-
- if (number >= 0) {
- down(&numspace_mutex);
- old_val = __test_and_clear_bit(number, s->bits);
- if (old_val)
- ++s->num_free;
- up(&numspace_mutex);
- }
-}
-
-static struct unique_numspace disc_numspace;
-static struct unique_numspace cdrom_numspace;
-
-void devfs_add_partitioned(struct gendisk *disk)
-{
- char dirname[64], symlink[16];
-
- devfs_mk_dir(disk->devfs_name);
- devfs_mk_bdev(MKDEV(disk->major, disk->first_minor),
- S_IFBLK|S_IRUSR|S_IWUSR,
- "%s/disc", disk->devfs_name);
-
- disk->number = alloc_unique_number(&disc_numspace);
-
- sprintf(symlink, "discs/disc%d", disk->number);
- sprintf(dirname, "../%s", disk->devfs_name);
- devfs_mk_symlink(symlink, dirname);
-
-}
-
-void devfs_add_disk(struct gendisk *disk)
-{
- devfs_mk_bdev(MKDEV(disk->major, disk->first_minor),
- (disk->flags & GENHD_FL_CD) ?
- S_IFBLK|S_IRUGO|S_IWUGO :
- S_IFBLK|S_IRUSR|S_IWUSR,
- "%s", disk->devfs_name);
-
- if (disk->flags & GENHD_FL_CD) {
- char dirname[64], symlink[16];
-
- disk->number = alloc_unique_number(&cdrom_numspace);
-
- sprintf(symlink, "cdroms/cdrom%d", disk->number);
- sprintf(dirname, "../%s", disk->devfs_name);
- devfs_mk_symlink(symlink, dirname);
- }
-}
-
-void devfs_remove_disk(struct gendisk *disk)
-{
- if (disk->minors != 1) {
- devfs_remove("discs/disc%d", disk->number);
- dealloc_unique_number(&disc_numspace, disk->number);
- devfs_remove("%s/disc", disk->devfs_name);
- }
- if (disk->flags & GENHD_FL_CD) {
- devfs_remove("cdroms/cdrom%d", disk->number);
- dealloc_unique_number(&cdrom_numspace, disk->number);
- }
- devfs_remove(disk->devfs_name);
-}
-
-
diff --git a/fs/partitions/devfs.h b/fs/partitions/devfs.h
deleted file mode 100644
--- a/fs/partitions/devfs.h
+++ /dev/null
@@ -1,10 +0,0 @@
-
-#ifdef CONFIG_DEVFS_FS
-void devfs_add_disk(struct gendisk *dev);
-void devfs_add_partitioned(struct gendisk *dev);
-void devfs_remove_disk(struct gendisk *dev);
-#else
-# define devfs_add_disk(disk) do { } while (0)
-# define devfs_add_partitioned(disk) do { } while (0)
-# define devfs_remove_disk(disk) do { } while (0)
-#endif

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

Andrew Morton

unread,

Jun 21, 2005, 4:18:13 AM6/21/05

to Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

Greg KH <gre...@suse.de> wrote:
>
> Just in time for a July release, here's a patch series that removes
> devfs from the kernel tree as promised.

Whimper.

Maybe we should cook this in -mm for a bit, get a feeling for how many
users hate us, and how much?

This is going to hurt:

bix:/usr/src/25> grep -l devfs patches/*.patch
patches/areca-raid-linux-scsi-driver-fix.patch
patches/areca-raid-linux-scsi-driver.patch
patches/bk-ide-dev.patch
patches/git-input.patch
patches/git-mtd.patch
patches/git-ocfs.patch
patches/git-scsi-misc-drivers-scsi-chc-remove-devfs-stuff.patch
patches/gregkh-driver-class-02-tty.patch
patches/gregkh-driver-class-03-input.patch
patches/gregkh-driver-class-05-sound.patch
patches/gregkh-driver-class-06-block.patch
patches/gregkh-driver-class-07-char.patch
patches/gregkh-driver-class-08-ieee1394.patch
patches/gregkh-driver-class-09-scsi.patch
patches/gregkh-driver-class-11-drivers.patch
patches/gregkh-driver-class-12-the_rest.patch
patches/gregkh-driver-ipmi-class_simple-fixes.patch
patches/gregkh-i2c-i2c-config_cleanup-01.patch
patches/kdump-accessing-dump-file-in-linear-raw-format.patch
patches/linus.patch
patches/md-add-interface-for-userspace-monitoring-of-events.patch
patches/md-optimised-resync-using-bitmap-based-intent-logging.patch
patches/post-halloween-doc.patch
patches/st-warning-fix.patch

Greg KH

unread,

Jun 21, 2005, 6:02:15 AM6/21/05

to Linus Torvalds, Andrew Morton, linux-...@vger.kernel.org

Just in time for a July release, here's a patch series that removes

devfs from the kernel tree as promised. This one incorporates all of
the suggestions from the previous posting of this set, and handles some
recent additions of new drivers to your git tree from the main 2.6.12
release.

Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/

Or if that hasn't synced yet from:
/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
on master.kernel.org

The full patch series will sent to the linux-kernel mailing list, if
anyone wants to see them.

thanks,

greg k-h

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

Greg Kroah-Hartman:
devfs: Last little devfs cleanups throughout the kernel tree.
devfs: Rename TTY_DRIVER_NO_DEVFS to TTY_DRIVER_DYNAMIC_DEV
devfs: Remove the mode field from usb_class_driver as it's no longer needed
devfs: Remove the tty_driver devfs_name field as it's no longer needed
devfs: Remove the scsi_disk devfs_name field as it's no longer needed
devfs: Remove the ide drive devfs_name field as it's no longer needed
devfs: Remove the line_driver devfs_name field as it's no longer needed
devfs: Remove the videodevice devfs_name field as it's no longer needed
devfs: Remove the gendisk devfs_name field as it's no longer needed
devfs: Remove the uart_driver devfs_name field as it's no longer needed
devfs: Remove the devfs_fs_kernel.h file from the tree
devfs: Remove the miscdevice devfs_name field as it's no longer needed
devfs: Remove devfs_remove() function from the kernel tree
devfs: Remove devfs_mk_cdev() function from the kernel tree
devfs: Remove devfs_mk_bdev() function from the kernel tree
devfs: Remove devfs_mk_dir() function from the kernel tree
devfs: Remove devfs_mk_symlink() function from the kernel tree
devfs: Remove devfs_*_tape() functions from the kernel tree
devfs: Remove devfs from the init code
devfs: Remove devfs from the kernel tree
devfs: Remove devfs documentation from the kernel tree

devfs: Remove devfs from the partition code

Adrian Bunk

unread,

Jun 21, 2005, 10:00:21 AM6/21/05

to Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

I don't see any place where this is not either:
- in documentation or
- already removed again in a second patch in -mm or
- only in patch context

Since the patch context issues are all in patches by Greg that went into
Linus' tree after 2.6.12-mm1 I doubt there will be many problems after
merging them.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Greg KH

unread,

Jun 21, 2005, 11:18:24 AM6/21/05

to Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Mon, Jun 20, 2005 at 11:54:03PM -0700, Andrew Morton wrote:

> Greg KH <gre...@suse.de> wrote:
> >
> > Just in time for a July release, here's a patch series that removes
> > devfs from the kernel tree as promised.
>
> Whimper.

Heh, you said you wanted me to merge my stuff before yours :)

> Maybe we should cook this in -mm for a bit, get a feeling for how many
> users hate us, and how much?

There might be some complaints. But I doubt they would be from anyone
running a -mm tree as those people kind of know the current status of
things in the kernel. There have been numerous warnings as to the fact
that this was going away, and I waited a _year_ to do this.

Also, no disto uses devfs only (gentoo is close, but offers users udev
and a static /dev also.)

> patches/areca-raid-linux-scsi-driver-fix.patch
> patches/areca-raid-linux-scsi-driver.patch

Shouldn't be hard

> patches/bk-ide-dev.patch
> patches/git-input.patch
> patches/git-mtd.patch
> patches/git-ocfs.patch

Merging will fix these

> patches/git-scsi-misc-drivers-scsi-chc-remove-devfs-stuff.patch

Sounds like you can drop this :)

> patches/gregkh-driver-class-02-tty.patch
> patches/gregkh-driver-class-03-input.patch
> patches/gregkh-driver-class-05-sound.patch
> patches/gregkh-driver-class-06-block.patch
> patches/gregkh-driver-class-07-char.patch
> patches/gregkh-driver-class-08-ieee1394.patch
> patches/gregkh-driver-class-09-scsi.patch
> patches/gregkh-driver-class-11-drivers.patch
> patches/gregkh-driver-class-12-the_rest.patch
> patches/gregkh-driver-ipmi-class_simple-fixes.patch
> patches/gregkh-i2c-i2c-config_cleanup-01.patch

I'll handle these

> patches/kdump-accessing-dump-file-in-linear-raw-format.patch

Should be easy.

> patches/linus.patch

Not relevant :)

> patches/md-add-interface-for-userspace-monitoring-of-events.patch
> patches/md-optimised-resync-using-bitmap-based-intent-logging.patch
> patches/post-halloween-doc.patch
> patches/st-warning-fix.patch

Again, shouldn't be that hard.

So there are probably 7 patches that need to get rediffed. In your
normal merges, I can't see that being all that difficult :)

Or I can wait until you go next. I didn't want these patches in the -mm
tree as they would have caused you too much work to keep up to date and
not conflict with anything else due to the size of them.

thanks,

greg k-h

Carsten Otte

unread,

Jun 21, 2005, 1:40:58 PM6/21/05

to Greg KH, Linus Torvalds, Andrew Morton, linux-...@vger.kernel.org, schwi...@de.ibm.com

As for our drivers, I don't see any breakage on reading the patches.
If it gets merged,
we should make sure to try it once before next release.

Andrew Morton

unread,

Jun 21, 2005, 4:18:34 PM6/21/05

to Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

Greg KH <gr...@kroah.com> wrote:
>
> Or I can wait until you go next. I didn't want these patches in the -mm
> tree as they would have caused you too much work to keep up to date and
> not conflict with anything else due to the size of them.

What happens if we merge it and then the storm of complaints over the
ensuing four weeks makes us say "whoops, shouldna done that [yet]"?

Greg KH

unread,

Jun 21, 2005, 5:28:32 PM6/21/05

to Andrew Morton, arj...@redhat.com, linux-...@vger.kernel.org, torv...@osdl.org

On Tue, Jun 21, 2005 at 02:03:10PM -0700, Andrew Morton wrote:
> Arjan van de Ven <arj...@redhat.com> wrote:

> >
> > On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > > Greg KH <gr...@kroah.com> wrote:
> > > >
> > > > Or I can wait until you go next. I didn't want these patches in the -mm
> > > > tree as they would have caused you too much work to keep up to date and
> > > > not conflict with anything else due to the size of them.
> > >
> > > What happens if we merge it and then the storm of complaints over the
> > > ensuing four weeks makes us say "whoops, shouldna done that [yet]"?
> >

> > so... disable the config option now. then wait 3 weeks. then do the
> > rest ;)
>
> That works for me?

Fine with me too. I'll whip up a patch to do just that.

thanks,

greg k-h

Andrew Morton

unread,

Jun 21, 2005, 5:52:54 PM6/21/05

to arj...@redhat.com, linux-...@vger.kernel.org, torv...@osdl.org, gr...@kroah.com

Arjan van de Ven <arj...@redhat.com> wrote:
>
> On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > Greg KH <gr...@kroah.com> wrote:
> > >
> > > Or I can wait until you go next. I didn't want these patches in the -mm
> > > tree as they would have caused you too much work to keep up to date and
> > > not conflict with anything else due to the size of them.
> >
> > What happens if we merge it and then the storm of complaints over the
> > ensuing four weeks makes us say "whoops, shouldna done that [yet]"?
>
> so... disable the config option now. then wait 3 weeks. then do the
> rest ;)

That works for me?

-

Arjan van de Ven

unread,

Jun 21, 2005, 6:00:45 PM6/21/05

to Andrew Morton, linux-...@vger.kernel.org, torv...@osdl.org, Greg KH

On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:

> Greg KH <gr...@kroah.com> wrote:
> >
> > Or I can wait until you go next. I didn't want these patches in the -mm
> > tree as they would have caused you too much work to keep up to date and
> > not conflict with anything else due to the size of them.
>
> What happens if we merge it and then the storm of complaints over the
> ensuing four weeks makes us say "whoops, shouldna done that [yet]"?

so... disable the config option now. then wait 3 weeks. then do the
rest ;)

undoing the config change is easy compared to undoing the rest...

signature.asc

J.A. Magallon

unread,

Jun 21, 2005, 7:29:43 PM6/21/05

to linux-...@vger.kernel.org

On 06.21, Greg KH wrote:
> On Tue, Jun 21, 2005 at 02:03:10PM -0700, Andrew Morton wrote:
> > Arjan van de Ven <arj...@redhat.com> wrote:
> > >
> > > On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > > > Greg KH <gr...@kroah.com> wrote:
> > > > >
> > > > > Or I can wait until you go next. I didn't want these patches in the -mm
> > > > > tree as they would have caused you too much work to keep up to date and
> > > > > not conflict with anything else due to the size of them.
> > > >
> > > > What happens if we merge it and then the storm of complaints over the
> > > > ensuing four weeks makes us say "whoops, shouldna done that [yet]"?
> > >
> > > so... disable the config option now. then wait 3 weeks. then do the
> > > rest ;)
> >
> > That works for me?
>
> Fine with me too. I'll whip up a patch to do just that.
>

Would you ship a new version of udev with all the *-devfs-* compat scripts
removed ?

--
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-jam1 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))

Mike Bell

unread,

Jun 22, 2005, 9:05:17 PM6/22/05

to Greg KH, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> There might be some complaints. But I doubt they would be from anyone
> running a -mm tree as those people kind of know the current status of
> things in the kernel. There have been numerous warnings as to the fact
> that this was going away, and I waited a _year_ to do this.

I use -mm and I'm complaining.

Knowing it's coming isn't the same as agreeing with it. :)

Once devfs is out, it's out for good. It is for all intents and purposes
impossible to maintain such a thing outside of mainline. You should know
that, udev's kernel infrastructure was developed pretty much entirely
within mainline and look how long it took to get even the present number
of drivers working with it.

It's pretty hard to put effort into devfs when said patches won't get
merged because it has already been decided by certain people that devfs
is not the way to go. For example the quick death without comment of the
earlier devfs-on-top-of-tmpfs patches.

Or, look at how hard of a time udev had gaining mindshare, how long it
was around for until now. Only shock tactics like marking devfs OBSOLETE
(at a time when udev was completely unready to replace devfs, making
it far from obsolete) got people switching.

> Also, no disto uses devfs only (gentoo is close, but offers users udev
> and a static /dev also.)

It breaks a lot of my embedded setups which have read-only storage only
and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
being - in my experience - still unready. Not to mention the general
bother of having to change dozens of desktop/server systems to work with
udev, but I doubt you care about that.

Andrew Morton

unread,

Jun 22, 2005, 9:22:16 PM6/22/05

to Mike Bell, gr...@kroah.com, gre...@suse.de, torv...@osdl.org, linux-...@vger.kernel.org

Mike Bell <ker...@mikebell.org> wrote:
>
> On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> > There might be some complaints. But I doubt they would be from anyone
> > running a -mm tree as those people kind of know the current status of
> > things in the kernel. There have been numerous warnings as to the fact
> > that this was going away, and I waited a _year_ to do this.
>
> I use -mm and I'm complaining.

Thanks!

> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs.

Well that's quite a problem. We're certainly causing people such as
yourself to take on quite a lot of work. But on the other hand we do want
the kernel to progress sanely, and that sometimes involves taking things
out.

I don't have enough info to know whether the world would be a better place
if we keep devfs, remove devfs or remove devfs even later on. I don't
think anyone knows, which is why we're taking this little
disable-it-and-see-who-shouts approach.

Bill Gatliff

unread,

Jun 22, 2005, 10:25:24 PM6/22/05

to linux-...@vger.kernel.org

Andrew:

>>It breaks a lot of my embedded setups which have read-only storage only
>>and thus need /dev on devfs or tmpfs.
>>
>>
>
>Well that's quite a problem. We're certainly causing people such as
>yourself to take on quite a lot of work. But on the other hand we do want
>the kernel to progress sanely, and that sometimes involves taking things
>out.
>
>I don't have enough info to know whether the world would be a better place
>if we keep devfs, remove devfs or remove devfs even later on. I don't
>think anyone knows, which is why we're taking this little
>disable-it-and-see-who-shouts approach.
>
>

I would prefer to keep devfs around as well, but most of my embedded
systems have enough RAM to put a primitive /dev tree in tmpfs using a
linuxrc script at boot. The workarounds for the userland requirements
of udev are a little less clear to me, but I'm not sure they're
insurmountable yet for anything except the smallest embedded systems,
since Busybox appears to have some udev support available now.

I think that devfs and udev appeal to different audiences, hence I don't
think you can say that the "world will be a better place" with one or
the other. It would be nice to find a way to have the two coexist
peacefully...

Case in point. I'm going to udev reluctantly; all my embedded work
based on earlier kernels used devfs exclusively.

b.g.

--
Bill Gatliff
So what part of:
$ make oldconfig clean dep zImage
do you not understand?
bg...@billgatliff.com

David Brownell

unread,

Jun 23, 2005, 12:11:53 AM6/23/05

to Linux Kernel list, ker...@mikebell.org

Quoth Mike Bell:

>
> > Also, no disto uses devfs only (gentoo is close, but offers users udev
> > and a static /dev also.)
>

> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs.

I'd agree that embedded setups are the ones that have been slowest to
switch over, for various reasons. One of them is that many LKML folk
ignore embedded systems issues; "just PC class or better". Another
has been that the basic hotplug scripts never worked well with "ash",
and who's going to want to ship "bash" and friends? :)

Those problems seem resolved with 2.6.12 and current modutils and udev.
Leaving basically an "upgrade your userspace" requirement.

> and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
> being - in my experience - still unready.

Hmm, could you explain why you think udev-on-ramfs/tmpfs/... is still
unready? And what it's "unready" for? It can work fine without
needing to hack early userspace and initramfs, by the way. :)

I recently submitted patches to make buildroot support it. They're
mostly merged [1] but adding a simple patch fixes up the remaining
glitches. OpenEmbedded has supported it for a while too.

In short, I think udev-on-ramfs is simple enough to set up on 2.6.12
based embedded configs, and with "modprobe -q $MODALIAS" phasing in,
it seems to me [2] that hotplug-with-udev [3] can do most of what
folk have used devfs to achieve. I've quilted buildroot so that it
works that way by default for me; it's turnkey, with no problems.

Of course, 2.6.13 will be better with cardmgr finally gone. :)

- Dave

[1] http://bugs.busybox.net/view.php?id=290
[2] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111903617808816&w=2
[3] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111903647518255&w=2

Greg KH

unread,

Jun 23, 2005, 1:04:07 AM6/23/05

to Mike Bell, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Jun 22, 2005 at 06:00:32PM -0700, Mike Bell wrote:
> On Tue, Jun 21, 2005 at 08:10:19AM -0700, Greg KH wrote:
> > There might be some complaints. But I doubt they would be from anyone
> > running a -mm tree as those people kind of know the current status of
> > things in the kernel. There have been numerous warnings as to the fact
> > that this was going away, and I waited a _year_ to do this.
>
> I use -mm and I'm complaining.
>
> Knowing it's coming isn't the same as agreeing with it. :)

I don't mean to pick on you, but this has been known for over a year
now, right? Hasn't anyone been preparing for any alternative situation
should this happen? I know some distros have, but it seems the embedded
people (you aren't the first to mention the "joys" of using devfs in
embedded systems) just have been hoping this wasn't going to happen.

Very odd...

> Once devfs is out, it's out for good. It is for all intents and purposes
> impossible to maintain such a thing outside of mainline.

Not true, look at how long it was maintained out of mainline to start
with. Using the tools we have today (like quilt and git) it should be
quite easy to keep the patch going if you really need it.

> You should know that, udev's kernel infrastructure was developed
> pretty much entirely within mainline and look how long it took to get
> even the present number of drivers working with it.

I do know that, but again, just reverse the patch and keep it going if
you really want to. All of the hard work is already done.

> > Also, no disto uses devfs only (gentoo is close, but offers users udev
> > and a static /dev also.)
>
> It breaks a lot of my embedded setups which have read-only storage only
> and thus need /dev on devfs or tmpfs. With early-userspace-udev-on-tmpfs
> being - in my experience - still unready.

Woah, I think Red Hat's and SuSE's "enterprise" distros would prove this
statement wrong. Also, there have been some people making some boot
images with udev in it for embedded systems that are almost a no-brainer
for someone to use (see the linux-hotplug-devel mailing list for more
info about this.)

> Not to mention the general bother of having to change dozens of
> desktop/server systems to work with udev, but I doubt you care about
> that.

I do care about this, please don't think that. But here's my reasoning
for why it needs to go:

- unmaintained for a number of years
- original developer of devfs has publicly stated udev is a
replacement.
- policy in the kernel.
- no distro uses it
- clutter and mess
- code is broken and unfixable
- udev is a full, and way more complete solution (it offers up
so much more than just a dynamic /dev. Way more than I ever
dreamed of.)
- companies are shipping, and supporting distros that use udev.
- It has been public knowledge that it would be removed for a
number of years, and the date has been specifically known for
the past year.

Are you really going to want to update a running system that uses devfs
to a newer kernel? If so, your distro will have a static /dev or a udev
package to replace it. If you aren't using your own distro, a drop-in
static /dev tree is a piece of cake for the short run, and udev is
simple to get up and running after that if you really want dynamic
stuff.

And again, for embedded systems, there are packages to build it and put
it in initramfs. People have already done the work for you.

thanks,

greg k-h

David Brownell

unread,

Jun 23, 2005, 1:13:56 AM6/23/05

to Linux Kernel list, Andrew Morton

Quoth Andrew Morton:

> I don't have enough info to know whether the world would be a better place
> if we keep devfs, remove devfs or remove devfs even later on. I don't
> think anyone knows, which is why we're taking this little
> disable-it-and-see-who-shouts approach.

The downside of "disable-and-remove-later" is that it becomes
too easy to just re-enable the Kconfig stuff rather than just
fixing the userspace bugs. Expecting userspace to change at
any point before it absolutely _must_ tends to be a formula
for userspace never changing, sadly enough.

If 2.6.13 doesn't remove devfs, when will it really go away?

- Dave

Bill Gatliff

unread,

Jun 23, 2005, 1:26:27 AM6/23/05

to Linux Kernel list

David:

David Brownell wrote:

>The downside of "disable-and-remove-later" is that it becomes
>too easy to just re-enable the Kconfig stuff rather than just
>fixing the userspace bugs. Expecting userspace to change at
>any point before it absolutely _must_ tends to be a formula
>for userspace never changing, sadly enough.
>
>If 2.6.13 doesn't remove devfs, when will it really go away?
>
>

Good point. I've come this far somewhat reluctantly, but can see that
udev is a better long-term solution. Once devfs is gone, it's easier
for me to justify doing the work to go fully over to udev (GregKH, can
you post a link or two to those "packages" you refer to?).

And also, once devfs is gone it's an easier economic decision for my
customers, too: either they move ahead and get whatever new features
that non-devfs kernels offer, or they do the work to keep the current
stuff in the state they want it. It's their call, I (sometimes) get
paid either way...

And it isn't like just my customers would be in this situation, everyone
will have to face it. So it's "fair" for everyone.

So, I guess I'm into the "say goodbye to devfs" camp now. In case
anyone asks, that is. :^)

b.g.

--
Bill Gatliff
Build a man a fire, and he's warm for the rest of the night.
Set a man on fire, and he's warm for the rest of his life.
-- Anonymous
bg...@billgatliff.com

Miles Bader

unread,

Jun 23, 2005, 2:23:47 AM6/23/05

to Greg KH, Mike Bell, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

Greg KH <gr...@kroah.com> writes:
> And again, for embedded systems, there are packages to build it and put
> it in initramfs. People have already done the work for you.

BTW, has anyone done a comparison of the space usage of udev vs. devfs
(including size of code etc....)?

Thanks,

-Miles
--
Run away! Run away!

Miles Bader

unread,

Jun 23, 2005, 2:53:53 AM6/23/05

to David Brownell, Linux Kernel list, ker...@mikebell.org

David Brownell <dav...@pacbell.net> writes:
> I'd agree that embedded setups are the ones that have been slowest to
> switch over, for various reasons. One of them is that many LKML folk
> ignore embedded systems issues; "just PC class or better".

I dunno about that -- while maybe the average LKMLer doesn't actively
worry so much about embedded issues, I've found many of them are very
friendly and helpful in getting patches for embedded/small-system
functionality cleaned up and merged into the mainstream kernel.

-miles
--
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964]

Miles Bader

unread,

Jun 23, 2005, 4:31:31 AM6/23/05

to Mike Bell, Miles Bader, Greg KH, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On 6/23/05, Mike Bell <ker...@mikebell.org> wrote:
> Greg gave me an "I assume so" estimate that udev was smaller by excluding
> the size of sysfs a while back. If you include sysfs in udev's overhead
> then I believe devfs wins handily, but I haven't done the numbers to
> prove it so my estimate is no better. I'm just basing it on sysfs being
> absolutely huge, in linux-tiny terms.

Is it? I always just sort of assumed that sysfs kernel support would
be more or less equivalent in size to devfs kernel support.

-Miles
--
Do not taunt Happy Fun Ball.

Andrew Morton

unread,

Jun 23, 2005, 4:31:31 AM6/23/05

to Mike Bell, mi...@gnu.org, gr...@kroah.com, gre...@suse.de, torv...@osdl.org, linux-...@vger.kernel.org

Mike Bell <ker...@mikebell.org> wrote:

>
> On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:
> > BTW, has anyone done a comparison of the space usage of udev vs. devfs
> > (including size of code etc....)?
>

> Greg gave me an "I assume so" estimate that udev was smaller by excluding
> the size of sysfs a while back. If you include sysfs in udev's overhead
> then I believe devfs wins handily, but I haven't done the numbers to
> prove it so my estimate is no better. I'm just basing it on sysfs being
> absolutely huge, in linux-tiny terms.

sysfs certainly has a history of goggling gobs of memory. But you can
disable it in .config.

Mike Bell

unread,

Jun 23, 2005, 4:31:31 AM6/23/05

to Andrew Morton, mi...@gnu.org, gr...@kroah.com, gre...@suse.de, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Jun 22, 2005 at 11:37:59PM -0700, Andrew Morton wrote:
> sysfs certainly has a history of goggling gobs of memory. But you can
> disable it in .config.

Right. Which breaks udev. Hence I say that if you're looking at "size of
devfs versus udev for solution X" and your devfs solution doesn't require
sysfs, then sysfs should be included in the size of udev for the sake of
the comparison.

Before anyone asks, that's not to say that sysfs is useless in a devfs
setting, merely that it's not required in most whereas it is required
for udev to even work.

Miles Bader

unread,

Jun 23, 2005, 4:31:36 AM6/23/05

to Greg KH, Miles Bader, Mike Bell, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On 6/23/05, Greg KH <gr...@kroah.com> wrote:
> Not that I know of. If you want to do this, compare the original udev
> releases that were around 5kb of code, as the nice features it has today
> are stuff that devfs can not support at all.

That wouldn't be such an effective tool for convincing people to
switch though... :-) "Look this obsolete version is much smaller!"

If udev has really bloated up due to whizzy new features, how hard
would it be to compile a stripped-down version? [Well I should look
at the busybox support somebody mentioned -- perhaps it's exactly
that.]

-Miles
--
Do not taunt Happy Fun Ball.

Mike Bell

unread,

Jun 23, 2005, 4:31:38 AM6/23/05

to Miles Bader, Greg KH, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:

> BTW, has anyone done a comparison of the space usage of udev vs. devfs
> (including size of code etc....)?

Greg gave me an "I assume so" estimate that udev was smaller by excluding

the size of sysfs a while back. If you include sysfs in udev's overhead
then I believe devfs wins handily, but I haven't done the numbers to
prove it so my estimate is no better. I'm just basing it on sysfs being
absolutely huge, in linux-tiny terms.

Mike Bell

unread,

Jun 23, 2005, 5:04:03 AM6/23/05

to Greg KH, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Jun 22, 2005 at 11:48:47PM -0700, Greg KH wrote:
> No, plan for it. Speak up. Complain sometime a while ago instead of
> right when it happens.

Did so. Raised the same points I'm doing now. Said at the time I was
going to wait and see if udev evolved to meet my needs before devfs got
removed. That time has arrived, and it hasn't, hence this. Seems
sensible to me.

> When did I ever say this? I have only ever said it was an option that
> people who want dynamic /dev and persistant naming can use. There are
> other projects out there becides udev that do much the same thing in
> userspace, udev isn't the only one.

But they all use fundamentally the same interface as udev and thus none
of them is any different with regard to my problems with udev, no?

> > Even before the official removal date was announced, vocal udev
> > proponents actively discouraged out-of-tree projects from accepting
> > devfs fixes.
> I was not aware of this.

Nonetheless true, and an example of the kind of problems maintaining
it out of tree would only make worse. And are you yourself not an
advocate of not caring if one breaks anything out of tree?

> He did, as did others. However no one actually did the work, and were
> persistant, which is what really matters in this community.

The process for getting code into mainline involves getting someone "in
the loop" to adopt your patch. If no one looks like they are going to do
that, your effort is wasted. What is one supposed to do?

> namespace policy does? Yes, the LANNANA one. A non-LSB standard should
> not.

> See the above point about LSB.

See my point about how I don't care about devfs's specific namescheme,
how driver authors should pick the names for their devices, and how if
you mean "these particular names don't belong in the kernel" you should
say as much, not "policy in kernel".

> But for persistant device naming, you need to do this in userspace, the
> kernel can not do it (and before the old ptx developers pipe up, yes,
> you all did do this within your kernel years ago, but your performance
> sucked and I'm not putting a whole database into our kernel...)

You can't reasonably have "this USB fob will always have this name but
another of the same make will have a different name" without userspace
help, nor should you, but you can have "all v4l devices show up in this
form" and the like. Which, for the vast majority of cases, is enough.

> udev allows different /dev naming schemes, even a devfs-compatible one
> so you don't have to change any other programs if you want so. devfs
> was unable to provide different ones.
>
> > As long as I can have my USB serial wireless modem named
> > "/dev/usb-serial-wireless-modem" via a symlink, why should I care that
> > the canonical name is something about USBttyS?
>
> dot-files will die that way :(

Not if they follow the symlink as they should.

> Becides them, no, you shouldn't, in fact, some distros use udev that way
> today.

So basically you've stated that this way of doing things is fine? And
since there's nothing to stop this way of doing things from happening
with devfs and a small, optional userspace helper to come up with
meaningful symlinked names based on logic that cannot reasonably be put
in the kernel....

> What distro shipps support for devfs and a 2.6 kernel? I am not aware
> of one (Gentoo doesn't count, they don't "ship" anything :) Honestly, I
> don't know of any. I do know of a lot of them that ship udev.

Debian? Their installer even relies on devfs instead of udev. And
following up absolute statements like "no distro uses it" with things
like "gentoo doesn't count" is why I never trust the things you say.
"udev is smaller than devfs", if you discount sysfs. Or earlier "udev
does everything devfs does" comments which were actually "can
theoretically do these things, but currently isn't implemented, and it
only works with a handful of devices"

> But it was unmaintained clutter and mess.

Which people have attempted to maintain. Presumably, had it not been
marked OBSOLETE and thus useless to bother maintaining in the eyes of
most, said patches would have gone in just like any other cleanup, and
just like devfs cleanups had been doing until that point.

> See Al Viro's comments about this, and then try to refute them. It's
> not just me saying this at all. In the end, no one has fixed them to
> prove him wrong so he might just be on to something...

If this is about the stupid race, I don't see why all of devfs should be
damned for a feature no one (to my knowledge) uses anyway and thus could
be easily ripped out without the objections of devfs-liking people. See
above comments about a single canonical name for devices.

> There is only 1 thing that I know of that devfs does that udev does not,
> auto-module-loading if you try to access a device node that isn't
> present. See my previous posts as to why this is a unworkable scheme
> anyway for 99% of the kernel devices. Yes, the other 1% can use this,
> like ppp and raw. But the distros have already solved this issue, so
> it's kind of moot.

I mentioned earlier that my main problems with udev were the continued
reliance on a partially static /dev, the way /dev is no longer
representative of the kernel's state, the reliance on sysfs to get any
usable system (assuming you treat static /dev as an unacceptable option,
which it is increasingly becoming) and most especially the early
userspace stuff. But before I assume you're making it up again I do need
to check your claims that these things have been addressed.

> Is there anything else that devfs can do that udev can't? I have a
> whole list of things that udev can do that devfs can not :)

But I'll wager none (well, not if you exclude
features-that-aren't-features in my mind like "not being devfs" and "not
having device names in the kernel) that I can't accomplish just fine on
a devfs using system, right? You said yourself that udev isn't intended
to be a dynamic dev, that's just a fringe benefit. So there's absolutely
nothing stopping me using hotplug and sysfs with devfs - as I do right
now - to gain the features of udev without losing devfs.

> > After being forced to do so by the sudden surprise deprication of devfs
> > and the ensuing publicity to udev.
>
> I have not forced _any_ company to do so. I have not even _asked_ any
> company to do so. I have simply been amazed that so many companies
> siezed on udev and brought it up to maturity and shipped it. That tells
> me that people really wanted it and see the advantages of it over devfs.

Mysteriously and coincidentally in a great burst around the time devfs
was marked obsolete and you repeatedly commented that people needed to
switch away from devfs or risk getting caught where I am now? :)

> I have not heard any such issues in the past 6 months. Hence my
> supprise now (well, not really supprise, I knew someone would complain,
> pretty amazed that it's only been one person in public (and one person
> privatly) so far.)

Because when patches to fix it get ignored, what else can one do? Who
wants to pipe up with "I like devfs" only to be told "you're stupid, if
you think you like devfs you don't understand udev" and knowing that
even saying so you don't really stand a chance of saving it?

> Then use the devfs mode of udev. The devfs author even sent me updates
> in order to get them to work properly for his machines...

The names aren't my concern, the early-boot behaviour, partially static
nature, and other such incompatibilities are.

> I have never, until now, forced anyone to use udev.

Technically true given the definition of the word "forced". But will you
not concede that the whole "OBSOLETE" thing, especially at such an early
stage in udev's maturity, was a good deal more of a strong-arm tactic
than the kernel usually sees?

> And even now, I'm not forcing anyone (there are other solutions to a
> dynamic /dev becides udev).

Yeah, the name of the userspace app doesn't mean a lot to me, they're
all forced to rely on the same kernel<=>userspace communication
mechanism and basically all work the same. I never complained about the
way udev handles its job in userspace, only about the removal of what
IMHO is a superior interface to kernelspace which offers things udev
alone cannot.

> I do feel, and it seems others agree, that udev is a far superior
> solution to the persistant device naming issue than devfs is

Wouldn't disagree with this. In fact, I'll come right out and say that
given the complete stagnation of devfs (which, I would argue, is not
entirely its own fault as you claim) and udev's rapid advances (based to
some degree I would argue on the attention it gained from things like
the marking of devfs obsolete) udev is the better solution today
(ignoring the migration headache and pretending both were completely new
systems introduced today, the features it offers that devfs doesn't are
worth much more than those devfs offers and udev doesn't, and it has a
much stronger community behind it).

But I also think that an even better solution could have been built
around the idea of a simple devfs that presented a single canonical
device file to userspace for each device and left the creation of
meaningful symlinks to an optional sysfs-using userspace helper. This
would have eliminated dependence on sysfs for the majority of systems I
know of, which rarely have custom rules giving more meaning to a device
than devfs currently presents, leaving me with all the features of devfs
I enjoy today and no migration headache, but a simple sysfs-using
userspace I could optionally apply to gain the features of udev. And
before you say something about "why didn't I then", I'd like to point
out that feature-wise I have that today, the only thing lacking is the
cleanups of devfs code, which really wasn't my primary concern and based
on the examples of others wouldn't have gotten in even if I had written
them.

So in closing, while I disagree with the whole way this has gone about,
in terms of things that can be done /now/ all I'm asking is that kernel
developers reevaluate the assumption that devfs is truly obsolete rather
than merely depricated, based on the fact that even after all this time
and energy udev is still not seen as a complete replacement by everyone.

Russell King

unread,

Jun 23, 2005, 5:13:47 AM6/23/05

to David Brownell, Linux Kernel list, ker...@mikebell.org

On Wed, Jun 22, 2005 at 09:08:50PM -0700, David Brownell wrote:
> I'd agree that embedded setups are the ones that have been slowest to
> switch over, for various reasons. One of them is that many LKML folk
> ignore embedded systems issues; "just PC class or better".

I don't think that's a fair comment - however I never read any of those
udev/devfs flamewars. As the lead developer of an embedded architecture,
I find that many people here do not take that attitude.

More the problem is that many embedded folk aren't here to air their
*technical* arguments because they can't keep up with the lkml traffic
level.

Consequently, lkml folk don't get the feedback from embedded folk, and
hence probably why udev doesn't/didn't work with ash.

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

Greg KH

unread,

Jun 23, 2005, 5:18:37 AM6/23/05

to Andrew Morton, Mike Bell, mi...@gnu.org, gre...@suse.de, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Jun 22, 2005 at 11:37:59PM -0700, Andrew Morton wrote:

> Mike Bell <ker...@mikebell.org> wrote:
> >
> > On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:
> > > BTW, has anyone done a comparison of the space usage of udev vs. devfs
> > > (including size of code etc....)?
> >
> > Greg gave me an "I assume so" estimate that udev was smaller by excluding
> > the size of sysfs a while back. If you include sysfs in udev's overhead
> > then I believe devfs wins handily, but I haven't done the numbers to
> > prove it so my estimate is no better. I'm just basing it on sysfs being
> > absolutely huge, in linux-tiny terms.
>
> sysfs certainly has a history of goggling gobs of memory. But you can
> disable it in .config.

Now the majority of sysfs memory is cachable and can get reclaimed quite
easily. The people running the 20,000 disk farms on a 31 bit
architecture made sure of that.

thanks,

greg k-h

Greg KH

unread,

Jun 23, 2005, 6:03:54 AM6/23/05

to snoggl...@gmail.com, mi...@gnu.org, Greg KH, Mike Bell, Andrew Morton, torv...@osdl.org, linux-...@vger.kernel.org

On Thu, Jun 23, 2005 at 03:36:11PM +0900, Miles Bader wrote:
> On 6/23/05, Greg KH <gr...@kroah.com> wrote:
> > Not that I know of. If you want to do this, compare the original udev
> > releases that were around 5kb of code, as the nice features it has today
> > are stuff that devfs can not support at all.
>
> That wouldn't be such an effective tool for convincing people to
> switch though... :-) "Look this obsolete version is much smaller!"
>
> If udev has really bloated up due to whizzy new features, how hard
> would it be to compile a stripped-down version? [Well I should look
> at the busybox support somebody mentioned -- perhaps it's exactly
> that.]

It wouldn't be that hard at all, just look at the first couple of
releases for example code to use (you would want it to be a totally
separate project, the current udev is not ment for such a stripped down
thing, it's ment to take over all of the /sbin/hotplug funcionality,
through netlink no less.)

thanks,

greg k-h

Greg KH

unread,

Jun 23, 2005, 6:03:54 AM6/23/05

to Mike Bell, Andrew Morton, Greg KH, torv...@osdl.org, linux-...@vger.kernel.org

On Wed, Jun 22, 2005 at 11:28:42PM -0700, Mike Bell wrote:

> On Wed, Jun 22, 2005 at 09:59:59PM -0700, Greg KH wrote:
> > I don't mean to pick on you, but this has been known for over a year
> > now, right? Hasn't anyone been preparing for any alternative situation
> > should this happen? I know some distros have, but it seems the embedded
> > people (you aren't the first to mention the "joys" of using devfs in
> > embedded systems) just have been hoping this wasn't going to happen.
> >
> > Very odd...
>

> What other choices are there? Fork the kernel?

No, plan for it. Speak up. Complain sometime a while ago instead of
right when it happens.

> > Not true, look at how long it was maintained out of mainline to start

> > with. Using the tools we have today (like quilt and git) it should be
> > quite easy to keep the patch going if you really need it.
>

> In an increasingly broken and harder to maintain state. Official
> blessing means a great deal.

I understand this.

> If you didn't know this, why did you go to such great lengths to state
> that udev was the official future path of the linux kernel?

When did I ever say this? I have only ever said it was an option that
people who want dynamic /dev and persistant naming can use. There are
other projects out there becides udev that do much the same thing in
userspace, udev isn't the only one.

> Even before the official removal date was announced, vocal udev

> proponents actively discouraged out-of-tree projects from accepting
> devfs fixes.

I was not aware of this.

> > I do care about this, please don't think that. But here's my reasoning

> > for why it needs to go:
>
> > - unmaintained for a number of years
>

> Semi-debatable. Even without a single maintainer, it has been getting
> fixes (just look at all the work that happened in the 2.5 series). And
> Adam J. Richter attempted to take over maintainership not long ago as I
> recall.

He did, as did others. However no one actually did the work, and were
persistant, which is what really matters in this community.

> > - policy in the kernel.
>
> Already exists.

namespace policy does? Yes, the LANNANA one. A non-LSB standard should
not.

> Don't see why /dev is policy in userspace but /proc and /sys aren't,
> or why a single canonical name set by the driver author with symlinks
> to whateverthehellyouwant isn't far super