[GIT PATCH] Remove devfs from 2.6.12-git

[GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

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


 Documentation/filesystems/devfs/ChangeLog         | 1977 ---------------
 Documentation/filesystems/devfs/README            | 1964 ---------------
 Documentation/filesystems/devfs/ToDo              |   40 
 Documentation/filesystems/devfs/boot-options      |   65 
 arch/i386/kernel/microcode.c                      |    1 
 arch/ppc/4xx_io/serial_sicc.c                     |    2 
 arch/sh/kernel/cpu/sh4/sq.c                       |    1 
 arch/sparc64/solaris/socksys.c                    |    4 
 arch/um/drivers/line.c                            |    2 
 arch/um/drivers/mmapper_kern.c                    |    1 
 arch/um/drivers/ssl.c                             |    1 
 arch/um/drivers/stdio_console.c                   |    1 
 arch/um/drivers/ubd_kern.c                        |   18 
 arch/um/include/line.h                            |    1 
 drivers/block/DAC960.c                            |    1 
 drivers/block/acsi.c                              |    5 
 drivers/block/acsi_slm.c                          |   10 
 drivers/block/cciss.c                             |    1 
 drivers/block/cpqarray.c                          |    5 
 drivers/block/floppy.c                            |   55 
 drivers/block/loop.c                              |    6 
 drivers/block/nbd.c                               |    5 
 drivers/block/paride/pg.c                         |   18 
 drivers/block/paride/pt.c                         |   21 
 drivers/block/pktcdvd.c                           |    1 
 drivers/block/ps2esdi.c                           |    1 
 drivers/block/rd.c                                |    5 
 drivers/block/swim3.c                             |    4 
 drivers/block/sx8.c                               |    5 
 drivers/block/ub.c                                |    6 
 drivers/block/umem.c                              |    1 
 drivers/block/viodasd.c                           |    3 
 drivers/block/xd.c                                |    1 
 drivers/block/z2ram.c                             |    1 
 drivers/cdrom/aztcd.c                             |    1 
 drivers/cdrom/cdu31a.c                            |    1 
 drivers/cdrom/cm206.c                             |    1 
 drivers/cdrom/gscd.c                              |    1 
 drivers/cdrom/mcdx.c                              |    1 
 drivers/cdrom/optcd.c                             |    1 
 drivers/cdrom/sbpcd.c                             |    6 
 drivers/cdrom/sjcd.c                              |    1 
 drivers/cdrom/sonycd535.c                         |    1 
 drivers/cdrom/viocd.c                             |    3 
 drivers/char/cyclades.c                           |    1 
 drivers/char/dsp56k.c                             |   10 
 drivers/char/dtlk.c                               |    5 
 drivers/char/epca.c                               |    1 
 drivers/char/esp.c                                |    1 
 drivers/char/ftape/zftape/zftape-init.c           |   25 
 drivers/char/hvc_console.c                        |    1 
 drivers/char/hvcs.c                               |    1 
 drivers/char/hvsi.c                               |    1 
 drivers/char/ip2main.c                            |   24 
 drivers/char/ipmi/ipmi_devintf.c                  |    8 
 drivers/char/isicom.c                             |    1 
 drivers/char/istallion.c                          |   13 
 drivers/char/lp.c                                 |    7 
 drivers/char/mem.c                                |    8 
 drivers/char/misc.c                               |   15 
 drivers/char/mmtimer.c                            |    2 
 drivers/char/moxa.c                               |    1 
 drivers/char/ppdev.c                              |   15 
 drivers/char/pty.c                                |    8 
 drivers/char/raw.c                                |   15 
 drivers/char/riscom8.c                            |    1 
 drivers/char/rocket.c                             |    5 
 drivers/char/serial167.c                          |    1 
 drivers/char/stallion.c                           |   14 
 drivers/char/tipar.c                              |   16 
 drivers/char/tty_io.c                             |   17 
 drivers/char/vc_screen.c                          |   11 
 drivers/char/viocons.c                            |    1 
 drivers/char/viotape.c                            |   10 
 drivers/char/vme_scc.c                            |    1 
 drivers/char/vt.c                                 |    2 
 drivers/i2c/i2c-dev.c                             |    7 
 drivers/ide/ide-cd.c                              |    2 
 drivers/ide/ide-disk.c                            |    2 
 drivers/ide/ide-floppy.c                          |    1 
 drivers/ide/ide-probe.c                           |   13 
 drivers/ide/ide-tape.c                            |   14 
 drivers/ide/ide.c                                 |   12 
 drivers/ieee1394/amdtp.c                          |   12 
 drivers/ieee1394/dv1394.c                         |   23 
 drivers/ieee1394/ieee1394_core.c                  |   16 
 drivers/ieee1394/ieee1394_core.h                  |    1 
 drivers/ieee1394/raw1394.c                        |    7 
 drivers/ieee1394/video1394.c                      |   14 
 drivers/input/evdev.c                             |    4 
 drivers/input/input.c                             |   11 
 drivers/input/joydev.c                            |    4 
 drivers/input/mousedev.c                          |    7 
 drivers/input/serio/serio_raw.c                   |    1 
 drivers/input/tsdev.c                             |    7 
 drivers/isdn/capi/capi.c                          |    5 
 drivers/isdn/hardware/eicon/divamnt.c             |    3 
 drivers/isdn/hardware/eicon/divasi.c              |    3 
 drivers/isdn/hardware/eicon/divasmain.c           |    3 
 drivers/isdn/i4l/isdn_tty.c                       |    3 
 drivers/macintosh/adb.c                           |    3 
 drivers/macintosh/macserial.c                     |    1 
 drivers/md/dm-ioctl.c                             |   30 
 drivers/md/dm.c                                   |    2 
 drivers/md/md.c                                   |   30 
 drivers/media/dvb/dvb-core/dvbdev.c               |   13 
 drivers/media/dvb/dvb-core/dvbdev.h               |    1 
 drivers/media/dvb/ttpci/av7110.h                  |    4 
 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |   11 
 drivers/media/radio/miropcm20-rds.c               |    1 
 drivers/media/video/arv.c                         |    1 
 drivers/media/video/videodev.c                    |   11 
 drivers/message/i2o/i2o_block.c                   |    1 
 drivers/mmc/mmc_block.c                           |    4 
 drivers/mtd/mtd_blkdevs.c                         |    6 
 drivers/mtd/mtdchar.c                             |   45 
 drivers/net/ppp_generic.c                         |    9 
 drivers/net/tun.c                                 |    1 
 drivers/net/wan/cosa.c                            |   14 
 drivers/s390/block/dasd.c                         |    4 
 drivers/s390/block/dasd_genhd.c                   |    2 
 drivers/s390/block/dasd_int.h                     |    1 
 drivers/s390/block/xpram.c                        |    6 
 drivers/s390/char/monreader.c                     |    1 
 drivers/s390/char/tty3270.c                       |    3 
 drivers/s390/crypto/z90main.c                     |    1 
 drivers/s390/net/ctctty.c                         |    2 
 drivers/sbus/char/bpp.c                           |    9 
 drivers/sbus/char/vfc.h                           |    2 
 drivers/sbus/char/vfc_dev.c                       |    7 
 drivers/scsi/ch.c                                 |    4 
 drivers/scsi/osst.c                               |   26 
 drivers/scsi/scsi.c                               |    3 
 drivers/scsi/scsi_scan.c                          |    6 
 drivers/scsi/sd.c                                 |    2 
 drivers/scsi/sg.c                                 |    9 
 drivers/scsi/sr.c                                 |    2 
 drivers/scsi/st.c                                 |   21 
 drivers/serial/21285.c                            |    1 
 drivers/serial/8250.c                             |    1 
 drivers/serial/au1x00_uart.c                      |    1 
 drivers/serial/crisv10.c                          |    2 
 drivers/serial/dz.c                               |    4 
 drivers/serial/imx.c                              |    1 
 drivers/serial/ip22zilog.c                        |    1 
 drivers/serial/m32r_sio.c                         |    1 
 drivers/serial/mcfserial.c                        |    1 
 drivers/serial/mpc52xx_uart.c                     |    1 
 drivers/serial/mpsc.c                             |    2 
 drivers/serial/pmac_zilog.c                       |    1 
 drivers/serial/pxa.c                              |    1 
 drivers/serial/s3c2410.c                          |    2 
 drivers/serial/sa1100.c                           |    1 
 drivers/serial/serial_core.c                      |    5 
 drivers/serial/serial_txx9.c                      |    3 
 drivers/serial/sh-sci.c                           |    3 
 drivers/serial/sunsab.c                           |    1 
 drivers/serial/sunsu.c                            |    1 
 drivers/serial/sunzilog.c                         |    1 
 drivers/serial/v850e_uart.c                       |    1 
 drivers/serial/vr41xx_siu.c                       |    1 
 drivers/tc/zs.c                                   |    3 
 drivers/telephony/phonedev.c                      |    4 
 drivers/usb/class/bluetty.c                       |    7 
 drivers/usb/class/cdc-acm.c                       |    3 
 drivers/usb/class/usblp.c                         |    3 
 drivers/usb/core/file.c                           |   19 
 drivers/usb/gadget/serial.c                       |    3 
 drivers/usb/image/mdc800.c                        |    3 
 drivers/usb/input/aiptek.c                        |    2 
 drivers/usb/input/hiddev.c                        |    6 
 drivers/usb/media/dabusb.c                        |    3 
 drivers/usb/misc/auerswald.c                      |    3 
 drivers/usb/misc/idmouse.c                        |    5 
 drivers/usb/misc/legousbtower.c                   |    5 
 drivers/usb/misc/rio500.c                         |    3 
 drivers/usb/misc/sisusbvga/sisusb.c               |    3 
 drivers/usb/misc/usblcd.c                         |    9 
 drivers/usb/serial/usb-serial.c                   |    3 
 drivers/usb/usb-skeleton.c                        |    7 
 drivers/video/fbmem.c                             |    5 
 fs/Kconfig                                        |   50 
 fs/Makefile                                       |    1 
 fs/block_dev.c                                    |    1 
 fs/char_dev.c                                     |    1 
 fs/coda/psdev.c                                   |   23 
 fs/compat_ioctl.c                                 |    1 
 fs/devfs/Makefile                                 |    8 
 fs/devfs/base.c                                   | 2838 ----------------------
 fs/devfs/util.c                                   |   97 
 fs/partitions/Makefile                            |    1 
 fs/partitions/check.c                             |   32 
 fs/partitions/devfs.c                             |  130 -
 fs/partitions/devfs.h                             |   10 
 include/asm-ppc/ocp.h                             |    1 
 include/linux/compat_ioctl.h                      |    5 
 include/linux/devfs_fs.h                          |   41 
 include/linux/devfs_fs_kernel.h                   |   58 
 include/linux/fb.h                                |    1 
 include/linux/genhd.h                             |    2 
 include/linux/ide.h                               |    1 
 include/linux/miscdevice.h                        |    1 
 include/linux/serial_core.h                       |    1 
 include/linux/tty_driver.h                        |   14 
 include/linux/usb.h                               |    7 
 include/linux/videodev.h                          |    1 
 include/scsi/scsi_device.h                        |    1 
 init/Makefile                                     |    1 
 init/do_mounts.c                                  |    8 
 init/do_mounts.h                                  |   16 
 init/do_mounts_devfs.c                            |  137 -
 init/do_mounts_initrd.c                           |    6 
 init/do_mounts_md.c                               |    7 
 init/do_mounts_rd.c                               |    4 
 init/main.c                                       |    1 
 mm/shmem.c                                        |    5 
 mm/tiny-shmem.c                                   |    4 
 net/bluetooth/rfcomm/tty.c                        |    3 
 net/irda/ircomm/ircomm_tty.c                      |    1 
 net/irda/irnet/irnet.h                            |    1 
 sound/core/info.c                                 |    1 
 sound/core/sound.c                                |   22 
 sound/oss/soundcard.c                             |   16 
 sound/sound_core.c                                |    6 
 224 files changed, 116 insertions(+), 8552 deletions(-)

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

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

 

[PATCH] devfs: Remove devfs from the partition code

[Greg KH]

[PATCH] devfs: Remove devfs from the partition code

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

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

---
commit 7780cade30d7fb5b9bebb67ccd5bb76f9a28fb23
tree 1484299b0a29203df4c9654eaff9197589247f5b
parent 7b9a41ff4e1a04c605f117cf1ee4e89c96be5c12
author Greg Kroah-Hartman <gregkh@suse.de> Mon, 20 Jun 2005 21:15:16 -0700
committer Greg Kroah-Hartman <gregkh@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Andrew Morton]

Greg KH <gregkh@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Adrian Bunk]

On Mon, Jun 20, 2005 at 11:54:03PM -0700, Andrew Morton wrote:
> Greg KH <gregkh@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

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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

On Mon, Jun 20, 2005 at 11:54:03PM -0700, Andrew Morton wrote:
> Greg KH <gregkh@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Andrew Morton]

Greg KH <greg@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]"?

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Arjan van de Ven]

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

On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> Greg KH <greg@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...


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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Andrew Morton]

Arjan van de Ven <arjanv@redhat.com> wrote:
>
> On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > Greg KH <greg@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?

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

On Tue, Jun 21, 2005 at 02:03:10PM -0700, Andrew Morton wrote:
> Arjan van de Ven <arjanv@redhat.com> wrote:
> >
> > On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > > Greg KH <greg@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[J.A. Magallon]

On 06.21, Greg KH wrote:
> On Tue, Jun 21, 2005 at 02:03:10PM -0700, Andrew Morton wrote:
> > Arjan van de Ven <arjanv@redhat.com> wrote:
> > >
> > > On Tue, 2005-06-21 at 13:11 -0700, Andrew Morton wrote:
> > > > Greg KH <greg@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))

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Andrew Morton]

Mike Bell <kernel@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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Bill Gatliff]

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?
bgat@billgatliff.com

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Miles Bader]

Greg KH <greg@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!

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:
> Greg KH <greg@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....)?

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.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Miles Bader]

On 6/23/05, Greg KH <greg@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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

On Thu, Jun 23, 2005 at 03:36:11PM +0900, Miles Bader wrote:
> On 6/23/05, Greg KH <greg@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Kay Sievers]

On Wed, Jun 22, 2005 at 11:26:27PM -0700, Greg KH wrote:
> On Thu, Jun 23, 2005 at 03:14:08PM +0900, Miles Bader wrote:
> > Greg KH <greg@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....)?
> 
> 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.

Sure, the main udev target is not the embedded world, just because there
is not such a big requirement to adapt a system to so many possible changes
that a desktop system or big servers seeing today.

But we have prepared the kernel with hotplug-events over netlink and a
full featured environment carried with the event. Instead of whining
about devfs going, start implementing your own tiny "udev" that even works
without sysfs at all:

  o Set /proc/sys/kernel/hotplug to "".

  o Create a single daemon that listens for netlink/events. Use $MAJOR $MINOR
    from the environment and create a node.

  o Define a simple kernel-name <-> node-name + action lookup table in the daemon
    If an action is defined, fork an event with the environment of the received
    netlink/event and handle the event externally.

  o For bootup, embedded setups can probably just use the minimal required set
    of nodes, which are copied over to the tmpfs /dev - mount. After
    real userspace is up, the daemon will take care of maintaining /dev.

That way, you have a nice replacement for devfs, /sbin/hotplug and using
$MODALIAS a replacement for most of the hotplug scripts.

Based on udevd.c in the current udev-tree one can do this in less than a
week, still enough time before devfs is removed. :)

Thanks,
Kay

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Andrew Morton]

Mike Bell <kernel@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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

On Wed, Jun 22, 2005 at 11:37:59PM -0700, Andrew Morton wrote:
> Mike Bell <kernel@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

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Miles Bader]

On 6/23/05, Mike Bell <kernel@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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

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?

> 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. 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? Even before the official removal date was announced,
vocal udev proponents actively discouraged out-of-tree projects from
accepting devfs fixes. Once it's removed, this becomes even worse.
Something like devfs (or the device model, or anything else core
infrastructurey) isn't possible without the cooperation of the community
in general, because it touches so much.

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

> 	- policy in the kernel.

Already exists. 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 superior. Fine, people
hate devfs's drive naming. I'm hardly a big fan of it either. But that
doesn't mean the idea of a single canonical naming scheme by which
userspace can consistently identify devices isn't a good one. As I
recall you even tried to propose such a scheme, albiet as overridable
policy in udev rather than in devfs, so you must recognize that there is
advantage to not having a different /dev naming scheme on every dist. 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?

> 	- no distro uses it

Bull. Complete. Can I claim by similar logic that no distro uses udev?

> 	- clutter and mess

Which is true of many other parts of the kernel, some of which were
cleaned up rather than being declared obsolete and preventing further
work to clean them up.

> 	- code is broken and unfixable

People attempting to fix the code might disagree. In fact, I'd consider
the claim that any code is "unfixable" pretty hard to back up logically.

> 	- 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.)

That works if you exclude all the things that devfs does that udev
doesn't, which you do because you consider them misfeatures, but that
kind of logic doesn't work for everyone.

> 	- companies are shipping, and supporting distros that use udev.

After being forced to do so by the sudden surprise deprication of devfs
and the ensuing publicity to 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.

Based somewhat on repeated statements that this was fait accompli. If
people are still using it and still consider udev not to be a complete
replacement, then the possibility of leaving it in the kernel should at
least be entertained. Not only is OSS still around for these reasons, but
even cryptoloop is still there! And unlike OSS and devfs, I haven't
recently heard anyone claim cryptoloop did something dm-crypt doesn't.

> Are you really going to want to update a running system that uses devfs
> to a newer kernel?

Why not? I've been doing it for over five years now. Or do you mean
change a running system using devfs to udev? No, I don't want to do that
at all, which is why I'm trying to get devfs left alone.

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

Well, in my case dynamic stuff is a prerequisite, while my servers would
all be fine with a static dev it would for all intents and purposes
destroy the functionality of my notebooks (practically everything is
dynamic. I can't even type on one without devfs.)

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

I'll look yet again, but I've been told that udev was "ready" when it
wasn't enough times now that I'm highly skeptical.

I've always considered myself an early adopter of "better" solutions. I
switched to devfs on my desktop the day it was put into mainline. I
invested a little time to switch from cryptoloop to dm-crypt for my
crypted-home-on-flash setup before dm-crypt was even in the kernel,
because I was won over by arguments that it was better. I always run the
current development series (when there is one) on at least one of my
machines, usually my main one. It's not like I'm resistant to change,
quite the opposite. I'm just plain unconvinced that udev is better in
every way to devfs. And the bizarre "force it down your throats" policy
that has characterized the udev over devfs saga has done little to
endear me to it.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

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 superior. Fine, people hate
> devfs's drive naming.

See the above point about LSB.

> I'm hardly a big fan of it either. But that doesn't mean the idea of a
> single canonical naming scheme by which userspace can consistently
> identify devices isn't a good one.

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...)

> As I recall you even tried to propose such a scheme, albiet as
> overridable policy in udev rather than in devfs, so you must recognize
> that there is advantage to not having a different /dev naming scheme
> on every dist.

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 :(

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

> > 	- no distro uses it
> 
> Bull. Complete. Can I claim by similar logic that no distro uses udev?

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.

> > 	- clutter and mess
> 
> Which is true of many other parts of the kernel, some of which were
> cleaned up rather than being declared obsolete and preventing further
> work to clean them up.

But it was unmaintained clutter and mess.

> > 	- code is broken and unfixable
> 
> People attempting to fix the code might disagree. In fact, I'd consider
> the claim that any code is "unfixable" pretty hard to back up logically.

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

> > 	- 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.)
> 
> That works if you exclude all the things that devfs does that udev
> doesn't, which you do because you consider them misfeatures, but that
> kind of logic doesn't work for everyone.

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.

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 :)

> > 	- companies are shipping, and supporting distros that use udev.
> 
> 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.

> > 	- 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.
> 
> Based somewhat on repeated statements that this was fait accompli.

Nothing is ever that way in our community, you should know that :)

> If people are still using it and still consider udev not to be a
> complete replacement, then the possibility of leaving it in the kernel
> should at least be entertained.

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.)

> Not only is OSS still around for these reasons, but
> even cryptoloop is still there! And unlike OSS and devfs, I haven't
> recently heard anyone claim cryptoloop did something dm-crypt doesn't.

Maybe no one has just taken the time and effort to want to remove
cryptoloop.  That's what it takes to get anything done around here...
Don't thing that lack of action always implies acceptance...

> > Are you really going to want to update a running system that uses devfs
> > to a newer kernel?
> 
> Why not? I've been doing it for over five years now. Or do you mean
> change a running system using devfs to udev? No, I don't want to do that
> at all, which is why I'm trying to get devfs left alone.

Ok, fair enough.

> > 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.
> 
> Well, in my case dynamic stuff is a prerequisite, while my servers would
> all be fine with a static dev it would for all intents and purposes
> destroy the functionality of my notebooks (practically everything is
> dynamic. I can't even type on one without devfs.)

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

> > And again, for embedded systems, there are packages to build it and
> > put it in initramfs.  People have already done the work for you.
> 
> I'll look yet again, but I've been told that udev was "ready" when it
> wasn't enough times now that I'm highly skeptical.

I would be glad to help out in any way, if you have any issues.  You
should post them to the linux-hotplug-devel mailing list so the other
udev developers can also help out.

> I've always considered myself an early adopter of "better" solutions. I
> switched to devfs on my desktop the day it was put into mainline. I
> invested a little time to switch from cryptoloop to dm-crypt for my
> crypted-home-on-flash setup before dm-crypt was even in the kernel,
> because I was won over by arguments that it was better. I always run the
> current development series (when there is one) on at least one of my
> machines, usually my main one. It's not like I'm resistant to change,
> quite the opposite. I'm just plain unconvinced that udev is better in
> every way to devfs. And the bizarre "force it down your throats" policy
> that has characterized the udev over devfs saga has done little to
> endear me to it.

I have never, until now, forced anyone to use udev.  And even now, I'm
not forcing anyone (there are other solutions to a dynamic /dev becides
udev).  I do feel, and it seems others agree, that udev is a far
superior solution to the persistant device naming issue than devfs is
(well, that's not really fair, as devfs can't even do that.)  As a
wonderful side affect, it also handles a dynamic /dev which other people
seem to like.

thanks,

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Mike Bell]

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.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Theodore Ts'o]

On Thu, Jun 23, 2005 at 01:29:00AM -0700, Mike Bell wrote:
> 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.

So send patches to udev.  You seem to be complaining, but not doing
any of the work to help the situation.  Views expressed in that
fashion generally don't get much consideration.  (Some, but not much.)

> Debian? Their installer even relies on devfs instead of udev. 

Debian's installer relies of devfs for historical reasons (it was too
hard to change without having sarge slip again for another year or
two); the system which is installed definitely does _not_ have to use
devfs, and _does_ ship with udev.  And the next version of Debian
(whenever it ships) will use something else.  See this URL in a
discussion filed regarding a _bug_ that was filed complaining that the
Debian installer was using devfs.

	http://lists.debian.org/debian-cd/2004/10/msg00012.html

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

Not many.  If someone had been willing to put in the _concerted_,
long-term effort that has been put in by people like Greg K-H to
develop an alternative system, including submitting a patch to remove
the racy bits of devfs (not clear if anything would be left :-), then
we would be in a different place.  But we haven't, so we're not.  One
or two proposals to do work, without followup patches (and fixes to
the patches after people complain/criticize them) means that whoever
claimed they were willing to do maintainance work weren't serious.

> 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).
> ...
> 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.

Is waiting another year really going to help?  If devfs is doomed,
then might as well make a clean break now.  Otherwise we'll wait
another year, and then more people will come out of the woodwork,
whining and whining for another stay of execution....

						- Ted

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Greg KH]

<flame war snipped>

I've taken the time that I would have spent responding to this email
thread, and to other people who for some reason don't like to respond to
mailing lists but want to pester me privatly with "don't delete devfs"
type emails, and written ndevfs, a replacement in less than 300 lines
(including all needed hooks in the kernel).

If this does not meet your needs to keep devfs for your embedded
systems, please respond to the ndevfs post with the patch on lkml.

greg k-h

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Per Liden]

On Wed, 22 Jun 2005, Greg KH wrote:

> 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:
[...]
> > > 	- no distro uses it
> > 
> > Bull. Complete. Can I claim by similar logic that no distro uses udev?
> 
> 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.

CRUX (http://crux.nu) is one example of such a dist.

/Per

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Richard Gooch]

Greg KH writes:
> I do care about this, please don't think that.  But here's my reasoning
> for why it needs to go:
[...]
> 	- original developer of devfs has publicly stated udev is a
> 	  replacement.

Well, that's news to me!

> 	- policy in the kernel.

Like sysfs :-)

> 	- clutter and mess

In the eye of the beholder.

> 	- code is broken and unfixable

No proof. Never say never...

				Regards,

					Richard....

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Jan Engelhardt]

>Greg KH writes:
>> I do care about this, please don't think that.  But here's my reasoning
>> for why it needs to go:
>[...]
>> 	- original developer of devfs has publicly stated udev is a
>> 	  replacement.
>
>Well, that's news to me!

What is more news to me: 
    ( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
    Q: Why was devfs marked OBSOLETE if udev is not finished yet?
    A: To quote Al Viro (Linux VFS kernel maintainer):
==> - the devfs maintainer/author disappeared and stoped maintaining the code

So, if you allow the question, where [t.h.] have you been in the meantime?

>> 	- clutter and mess
>In the eye of the beholder.
It's kernel code - I think the point is valid.

>> 	- code is broken and unfixable
>No proof. Never say never...

*thumbs up* You could just become the maintainer of ndevfs. :)


Something's wondering me, though:
FreeBSD "just" (5.0) introduced devfs, so either they are behind The Facts 
(see udev FAQ), or devfs (anylinux/anybsd) is not so bad after all.



Jan Engelhardt
-- 

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Daniel Phillips]

On Tuesday 19 July 2005 06:12, Jan Engelhardt wrote:
> What is more news to me:
>     ( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
>     Q: Why was devfs marked OBSOLETE if udev is not finished yet?
>     A: To quote Al Viro (Linux VFS kernel maintainer):
> ==> - the devfs maintainer/author disappeared and stoped maintaining the
> code

Chased out by the same Al Viro, more like it.  Not that I like devfs at all, 
but it's a shame to see such revisionism in an otherwise respectable 
document.

Regards,

Daniel

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Jim Crilly]

On 07/18/05 10:12:29PM +0200, Jan Engelhardt wrote:
> 
> Something's wondering me, though:
> FreeBSD "just" (5.0) introduced devfs, so either they are behind The Facts 
> (see udev FAQ), or devfs (anylinux/anybsd) is not so bad after all.

There's not much to wonder about here, the basic idea of devfs is a good
one which is why udev was written. The problems expressed on lkml about
devfs were with that specifically implementation, if a better
implementation had been merged originally udev might have never been
created. I really doubt FreeBSD took the Linux devfs code and integrated it
with their kernel, so the fact that FreeBSD is using a devfs now simply
means they like the idea of a dynamic /dev as well.

> 
> 
> 
> Jan Engelhardt

Jim.

Re: [GIT PATCH] Remove devfs from 2.6.12-git

[Carsten Otte]

On 6/21/05, Greg KH <gregkh@suse.de> wrote:
>  drivers/s390/block/dasd.c                         |    4
>  drivers/s390/block/dasd_genhd.c                   |    2
>  drivers/s390/block/dasd_int.h                     |    1
>  drivers/s390/block/xpram.c                        |    6
>  drivers/s390/char/monreader.c                     |    1
>  drivers/s390/char/tty3270.c                       |    3
>  drivers/s390/crypto/z90main.c                     |    1
>  drivers/s390/net/ctctty.c                         |    2
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.