LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] Delete obsolete RAW driver feature.
@ 2007-03-18 11:59 Robert P. J. Day
  2007-03-18 15:57 ` Andi Kleen
  0 siblings, 1 reply; 21+ messages in thread
From: Robert P. J. Day @ 2007-03-18 11:59 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: Andrew Morton, Adrian Bunk


Delete the allegedly obsolete raw driver feature, which has been
marked for death since 2005.

Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>

---
  compile-tested with "make allyesconfig" under x86.


 Documentation/feature-removal-schedule.txt |    8
 Documentation/ioctl-number.txt             |    1
 drivers/char/Kconfig                       |   21 -
 drivers/char/Makefile                      |    1
 drivers/char/mem.c                         |    1
 drivers/char/raw.c                         |  306 -------------------
 fs/compat_ioctl.c                          |   71 ----
 include/linux/Kbuild                       |    1
 include/linux/compat_ioctl.h               |    3
 include/linux/raw.h                        |   18 -
 10 files changed, 431 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c585aa8..29bdd4d 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who:	Pavel Machek <pavel@suse.cz>

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

-What:	RAW driver (CONFIG_RAW_DRIVER)
-When:	December 2005
-Why:	declared obsolete since kernel 2.6.3
-	O_DIRECT can be used instead
-Who:	Adrian Bunk <bunk@stusta.de>
-
----------------------------
-
 What:	raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:	June 2007
 Why:	Deprecated in favour of the more efficient and robust rawiso interface.
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 8f750c0..96a3b91 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -178,7 +178,6 @@ Code	Seq#	Include File		Comments
 					<mailto:tlewis@mindspring.com>
 0xA3	90-9F	linux/dtlk.h
 0xAB	00-1F	linux/nbd.h
-0xAC	00-1F	linux/raw.h
 0xAD	00	Netfilter device	in development:
 					<mailto:rusty@rustcorp.com.au>
 0xB0	all	RATIO devices		in development:
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index d0a6dc5..560fbe8 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -955,27 +955,6 @@ config GPIO_VR41XX
 	tristate "NEC VR4100 series General-purpose I/O Unit support"
 	depends on CPU_VR41XX

-config RAW_DRIVER
-	tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
-	depends on BLOCK
-	help
-	  The raw driver permits block devices to be bound to /dev/raw/rawN.
-	  Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
-	  See the raw(8) manpage for more details.
-
-          The raw driver is deprecated and will be removed soon.
-          Applications should simply open the device (eg /dev/hda1)
-          with the O_DIRECT flag.
-
-config MAX_RAW_DEVS
-	int "Maximum number of RAW devices to support (1-8192)"
-	depends on RAW_DRIVER
-	default "256"
-	help
-	  The maximum number of RAW devices that are supported.
-	  Default is 256. Increase this number in case you need lots of
-	  raw devices.
-
 config HPET
 	bool "HPET - High Precision Event Timer" if (X86 || IA64)
 	default n
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index ae8567c..65df838 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -47,7 +47,6 @@ obj-$(CONFIG_HVC_ISERIES)	+= hvc_iseries.o
 obj-$(CONFIG_HVC_RTAS)		+= hvc_rtas.o
 obj-$(CONFIG_HVC_BEAT)		+= hvc_beat.o
 obj-$(CONFIG_HVC_DRIVER)	+= hvc_console.o
-obj-$(CONFIG_RAW_DRIVER)	+= raw.o
 obj-$(CONFIG_SGI_SNSC)		+= snsc.o snsc_event.o
 obj-$(CONFIG_MSPEC)		+= mspec.o
 obj-$(CONFIG_MMTIMER)		+= mmtimer.o
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f5c160c..8df68d7 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -15,7 +15,6 @@
 #include <linux/mman.h>
 #include <linux/random.h>
 #include <linux/init.h>
-#include <linux/raw.h>
 #include <linux/tty.h>
 #include <linux/capability.h>
 #include <linux/smp_lock.h>
diff --git a/drivers/char/raw.c b/drivers/char/raw.c
deleted file mode 100644
index 1f0d7c6..0000000
--- a/drivers/char/raw.c
+++ /dev/null
@@ -1,306 +0,0 @@
-/*
- * linux/drivers/char/raw.c
- *
- * Front-end raw character devices.  These can be bound to any block
- * devices to provide genuine Unix raw character device semantics.
- *
- * We reserve minor number 0 for a control interface.  ioctl()s on this
- * device are used to bind the other minor numbers to block devices.
- */
-
-#include <linux/init.h>
-#include <linux/fs.h>
-#include <linux/major.h>
-#include <linux/blkdev.h>
-#include <linux/module.h>
-#include <linux/raw.h>
-#include <linux/capability.h>
-#include <linux/uio.h>
-#include <linux/cdev.h>
-#include <linux/device.h>
-#include <linux/mutex.h>
-
-#include <asm/uaccess.h>
-
-struct raw_device_data {
-	struct block_device *binding;
-	int inuse;
-};
-
-static struct class *raw_class;
-static struct raw_device_data raw_devices[MAX_RAW_MINORS];
-static DEFINE_MUTEX(raw_mutex);
-static const struct file_operations raw_ctl_fops; /* forward declaration */
-
-/*
- * Open/close code for raw IO.
- *
- * We just rewrite the i_mapping for the /dev/raw/rawN file descriptor to
- * point at the blockdev's address_space and set the file handle to use
- * O_DIRECT.
- *
- * Set the device's soft blocksize to the minimum possible.  This gives the
- * finest possible alignment and has no adverse impact on performance.
- */
-static int raw_open(struct inode *inode, struct file *filp)
-{
-	const int minor = iminor(inode);
-	struct block_device *bdev;
-	int err;
-
-	if (minor == 0) {	/* It is the control device */
-		filp->f_op = &raw_ctl_fops;
-		return 0;
-	}
-
-	mutex_lock(&raw_mutex);
-
-	/*
-	 * All we need to do on open is check that the device is bound.
-	 */
-	bdev = raw_devices[minor].binding;
-	err = -ENODEV;
-	if (!bdev)
-		goto out;
-	igrab(bdev->bd_inode);
-	err = blkdev_get(bdev, filp->f_mode, 0);
-	if (err)
-		goto out;
-	err = bd_claim(bdev, raw_open);
-	if (err)
-		goto out1;
-	err = set_blocksize(bdev, bdev_hardsect_size(bdev));
-	if (err)
-		goto out2;
-	filp->f_flags |= O_DIRECT;
-	filp->f_mapping = bdev->bd_inode->i_mapping;
-	if (++raw_devices[minor].inuse == 1)
-		filp->f_path.dentry->d_inode->i_mapping =
-			bdev->bd_inode->i_mapping;
-	filp->private_data = bdev;
-	mutex_unlock(&raw_mutex);
-	return 0;
-
-out2:
-	bd_release(bdev);
-out1:
-	blkdev_put(bdev);
-out:
-	mutex_unlock(&raw_mutex);
-	return err;
-}
-
-/*
- * When the final fd which refers to this character-special node is closed, we
- * make its ->mapping point back at its own i_data.
- */
-static int raw_release(struct inode *inode, struct file *filp)
-{
-	const int minor= iminor(inode);
-	struct block_device *bdev;
-
-	mutex_lock(&raw_mutex);
-	bdev = raw_devices[minor].binding;
-	if (--raw_devices[minor].inuse == 0) {
-		/* Here  inode->i_mapping == bdev->bd_inode->i_mapping  */
-		inode->i_mapping = &inode->i_data;
-		inode->i_mapping->backing_dev_info = &default_backing_dev_info;
-	}
-	mutex_unlock(&raw_mutex);
-
-	bd_release(bdev);
-	blkdev_put(bdev);
-	return 0;
-}
-
-/*
- * Forward ioctls to the underlying block device.
- */
-static int
-raw_ioctl(struct inode *inode, struct file *filp,
-		  unsigned int command, unsigned long arg)
-{
-	struct block_device *bdev = filp->private_data;
-
-	return blkdev_ioctl(bdev->bd_inode, NULL, command, arg);
-}
-
-static void bind_device(struct raw_config_request *rq)
-{
-	device_destroy(raw_class, MKDEV(RAW_MAJOR, rq->raw_minor));
-	device_create(raw_class, NULL, MKDEV(RAW_MAJOR, rq->raw_minor),
-		      "raw%d", rq->raw_minor);
-}
-
-/*
- * Deal with ioctls against the raw-device control interface, to bind
- * and unbind other raw devices.
- */
-static int raw_ctl_ioctl(struct inode *inode, struct file *filp,
-			unsigned int command, unsigned long arg)
-{
-	struct raw_config_request rq;
-	struct raw_device_data *rawdev;
-	int err = 0;
-
-	switch (command) {
-	case RAW_SETBIND:
-	case RAW_GETBIND:
-
-		/* First, find out which raw minor we want */
-
-		if (copy_from_user(&rq, (void __user *) arg, sizeof(rq))) {
-			err = -EFAULT;
-			goto out;
-		}
-
-		if (rq.raw_minor <= 0 || rq.raw_minor >= MAX_RAW_MINORS) {
-			err = -EINVAL;
-			goto out;
-		}
-		rawdev = &raw_devices[rq.raw_minor];
-
-		if (command == RAW_SETBIND) {
-			dev_t dev;
-
-			/*
-			 * This is like making block devices, so demand the
-			 * same capability
-			 */
-			if (!capable(CAP_SYS_ADMIN)) {
-				err = -EPERM;
-				goto out;
-			}
-
-			/*
-			 * For now, we don't need to check that the underlying
-			 * block device is present or not: we can do that when
-			 * the raw device is opened.  Just check that the
-			 * major/minor numbers make sense.
-			 */
-
-			dev = MKDEV(rq.block_major, rq.block_minor);
-			if ((rq.block_major == 0 && rq.block_minor != 0) ||
-					MAJOR(dev) != rq.block_major ||
-					MINOR(dev) != rq.block_minor) {
-				err = -EINVAL;
-				goto out;
-			}
-
-			mutex_lock(&raw_mutex);
-			if (rawdev->inuse) {
-				mutex_unlock(&raw_mutex);
-				err = -EBUSY;
-				goto out;
-			}
-			if (rawdev->binding) {
-				bdput(rawdev->binding);
-				module_put(THIS_MODULE);
-			}
-			if (rq.block_major == 0 && rq.block_minor == 0) {
-				/* unbind */
-				rawdev->binding = NULL;
-				device_destroy(raw_class,
-						MKDEV(RAW_MAJOR, rq.raw_minor));
-			} else {
-				rawdev->binding = bdget(dev);
-				if (rawdev->binding == NULL)
-					err = -ENOMEM;
-				else {
-					__module_get(THIS_MODULE);
-					bind_device(&rq);
-				}
-			}
-			mutex_unlock(&raw_mutex);
-		} else {
-			struct block_device *bdev;
-
-			mutex_lock(&raw_mutex);
-			bdev = rawdev->binding;
-			if (bdev) {
-				rq.block_major = MAJOR(bdev->bd_dev);
-				rq.block_minor = MINOR(bdev->bd_dev);
-			} else {
-				rq.block_major = rq.block_minor = 0;
-			}
-			mutex_unlock(&raw_mutex);
-			if (copy_to_user((void __user *)arg, &rq, sizeof(rq))) {
-				err = -EFAULT;
-				goto out;
-			}
-		}
-		break;
-	default:
-		err = -EINVAL;
-		break;
-	}
-out:
-	return err;
-}
-
-static const struct file_operations raw_fops = {
-	.read	=	do_sync_read,
-	.aio_read = 	generic_file_aio_read,
-	.write	=	do_sync_write,
-	.aio_write = 	generic_file_aio_write_nolock,
-	.open	=	raw_open,
-	.release=	raw_release,
-	.ioctl	=	raw_ioctl,
-	.owner	=	THIS_MODULE,
-};
-
-static const struct file_operations raw_ctl_fops = {
-	.ioctl	=	raw_ctl_ioctl,
-	.open	=	raw_open,
-	.owner	=	THIS_MODULE,
-};
-
-static struct cdev raw_cdev = {
-	.kobj	=	{.name = "raw", },
-	.owner	=	THIS_MODULE,
-};
-
-static int __init raw_init(void)
-{
-	dev_t dev = MKDEV(RAW_MAJOR, 0);
-	int ret;
-
-	ret = register_chrdev_region(dev, MAX_RAW_MINORS, "raw");
-	if (ret)
-		goto error;
-
-	cdev_init(&raw_cdev, &raw_fops);
-	ret = cdev_add(&raw_cdev, dev, MAX_RAW_MINORS);
-	if (ret) {
-		kobject_put(&raw_cdev.kobj);
-		goto error_region;
-	}
-
-	raw_class = class_create(THIS_MODULE, "raw");
-	if (IS_ERR(raw_class)) {
-		printk(KERN_ERR "Error creating raw class.\n");
-		cdev_del(&raw_cdev);
-		ret = PTR_ERR(raw_class);
-		goto error_region;
-	}
-	device_create(raw_class, NULL, MKDEV(RAW_MAJOR, 0), "rawctl");
-
-	return 0;
-
-error_region:
-	unregister_chrdev_region(dev, MAX_RAW_MINORS);
-error:
-	return ret;
-}
-
-static void __exit raw_exit(void)
-{
-	device_destroy(raw_class, MKDEV(RAW_MAJOR, 0));
-	class_destroy(raw_class);
-	cdev_del(&raw_cdev);
-	unregister_chrdev_region(MKDEV(RAW_MAJOR, 0), MAX_RAW_MINORS);
-}
-
-module_init(raw_init);
-module_exit(raw_exit);
-MODULE_LICENSE("GPL");
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index c81c958..a1b438b 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -47,7 +47,6 @@
 #include <linux/fb.h>
 #include <linux/videodev.h>
 #include <linux/netdevice.h>
-#include <linux/raw.h>
 #include <linux/smb_fs.h>
 #include <linux/blkpg.h>
 #include <linux/blkdev.h>
@@ -1949,73 +1948,6 @@ static int mtd_rw_oob(unsigned int fd, unsigned int cmd, unsigned long arg)
 	return err;
 }

-#ifdef CONFIG_BLOCK
-struct raw32_config_request
-{
-        compat_int_t    raw_minor;
-        __u64   block_major;
-        __u64   block_minor;
-} __attribute__((packed));
-
-static int get_raw32_request(struct raw_config_request *req, struct raw32_config_request __user *user_req)
-{
-        int ret;
-
-        if (!access_ok(VERIFY_READ, user_req, sizeof(struct raw32_config_request)))
-                return -EFAULT;
-
-        ret = __get_user(req->raw_minor, &user_req->raw_minor);
-        ret |= __get_user(req->block_major, &user_req->block_major);
-        ret |= __get_user(req->block_minor, &user_req->block_minor);
-
-        return ret ? -EFAULT : 0;
-}
-
-static int set_raw32_request(struct raw_config_request *req, struct raw32_config_request __user *user_req)
-{
-	int ret;
-
-        if (!access_ok(VERIFY_WRITE, user_req, sizeof(struct raw32_config_request)))
-                return -EFAULT;
-
-        ret = __put_user(req->raw_minor, &user_req->raw_minor);
-        ret |= __put_user(req->block_major, &user_req->block_major);
-        ret |= __put_user(req->block_minor, &user_req->block_minor);
-
-        return ret ? -EFAULT : 0;
-}
-
-static int raw_ioctl(unsigned fd, unsigned cmd, unsigned long arg)
-{
-        int ret;
-
-        switch (cmd) {
-        case RAW_SETBIND:
-        case RAW_GETBIND: {
-                struct raw_config_request req;
-                struct raw32_config_request __user *user_req = compat_ptr(arg);
-                mm_segment_t oldfs = get_fs();
-
-                if ((ret = get_raw32_request(&req, user_req)))
-                        return ret;
-
-                set_fs(KERNEL_DS);
-                ret = sys_ioctl(fd,cmd,(unsigned long)&req);
-                set_fs(oldfs);
-
-                if ((!ret) && (cmd == RAW_GETBIND)) {
-                        ret = set_raw32_request(&req, user_req);
-                }
-                break;
-        }
-        default:
-                ret = sys_ioctl(fd, cmd, arg);
-                break;
-        }
-        return ret;
-}
-#endif /* CONFIG_BLOCK */
-
 struct serial_struct32 {
         compat_int_t    type;
         compat_int_t    line;
@@ -2521,9 +2453,6 @@ HANDLE_IOCTL(SONET_GETFRSENSE, do_atm_ioctl)
 HANDLE_IOCTL(BLKBSZGET_32, do_blkbszget)
 HANDLE_IOCTL(BLKBSZSET_32, do_blkbszset)
 HANDLE_IOCTL(BLKGETSIZE64_32, do_blkgetsize64)
-/* Raw devices */
-HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
-HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
 #endif
 /* Serial */
 HANDLE_IOCTL(TIOCGSERIAL, serial_struct_ioctl)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index e81e301..b1acdac 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -132,7 +132,6 @@ header-y += qnxtypes.h
 header-y += quotaio_v1.h
 header-y += quotaio_v2.h
 header-y += radeonfb.h
-header-y += raw.h
 header-y += resource.h
 header-y += rose.h
 header-y += smbno.h
diff --git a/include/linux/compat_ioctl.h b/include/linux/compat_ioctl.h
index c26c3ad..cd56780 100644
--- a/include/linux/compat_ioctl.h
+++ b/include/linux/compat_ioctl.h
@@ -571,9 +571,6 @@ COMPATIBLE_IOCTL(AUTOFS_IOC_PROTOSUBVER)
 COMPATIBLE_IOCTL(AUTOFS_IOC_ASKREGHOST)
 COMPATIBLE_IOCTL(AUTOFS_IOC_TOGGLEREGHOST)
 COMPATIBLE_IOCTL(AUTOFS_IOC_ASKUMOUNT)
-/* Raw devices */
-COMPATIBLE_IOCTL(RAW_SETBIND)
-COMPATIBLE_IOCTL(RAW_GETBIND)
 /* SMB ioctls which do not need any translations */
 COMPATIBLE_IOCTL(SMB_IOC_NEWCONN)
 /* Little a */
diff --git a/include/linux/raw.h b/include/linux/raw.h
deleted file mode 100644
index 62d543e..0000000
--- a/include/linux/raw.h
+++ /dev/null
@@ -1,18 +0,0 @@
-#ifndef __LINUX_RAW_H
-#define __LINUX_RAW_H
-
-#include <linux/types.h>
-
-#define RAW_SETBIND	_IO( 0xac, 0 )
-#define RAW_GETBIND	_IO( 0xac, 1 )
-
-struct raw_config_request
-{
-	int	raw_minor;
-	__u64	block_major;
-	__u64	block_minor;
-};
-
-#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
-
-#endif /* __LINUX_RAW_H */
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-18 15:57 ` Andi Kleen
@ 2007-03-18 15:38   ` Robert P. J. Day
  2007-03-20 16:57   ` Dave Jones
  1 sibling, 0 replies; 21+ messages in thread
From: Robert P. J. Day @ 2007-03-18 15:38 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Linux Kernel Mailing List, Andrew Morton, Adrian Bunk

On Sun, 18 Mar 2007, Andi Kleen wrote:

> "Robert P. J. Day" <rpjday@mindspring.com> writes:
>
> > Delete the allegedly obsolete raw driver feature, which has been
> > marked for death since 2005.
>
> I think it would be better to replace it with a wrapper that forces
> O_DIRECT and opens the underlying block device.  I suspect just
> dropping it will break many people's database setups, which is not
> nice.  Widely used admin interfaces should be only broken when there
> is a very good reason and just "there is a better way now" doesn't
> seem quite strong enough.

ok, i'll leave that in the hands of those higher up the food chain.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-18 11:59 [PATCH] Delete obsolete RAW driver feature Robert P. J. Day
@ 2007-03-18 15:57 ` Andi Kleen
  2007-03-18 15:38   ` Robert P. J. Day
  2007-03-20 16:57   ` Dave Jones
  0 siblings, 2 replies; 21+ messages in thread
From: Andi Kleen @ 2007-03-18 15:57 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List, Andrew Morton, Adrian Bunk

"Robert P. J. Day" <rpjday@mindspring.com> writes:

> Delete the allegedly obsolete raw driver feature, which has been
> marked for death since 2005.

I think it would be better to replace it with a wrapper
that forces O_DIRECT and opens the underlying block device.  I suspect 
just dropping it will break many people's database setups, which is not
nice.  Widely used admin interfaces should be only broken when 
there is a very good reason and just "there is a better way now" 
doesn't seem quite strong enough.

-Andi

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-18 15:57 ` Andi Kleen
  2007-03-18 15:38   ` Robert P. J. Day
@ 2007-03-20 16:57   ` Dave Jones
  2007-03-20 18:14     ` Alan Cox
  1 sibling, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-20 16:57 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Robert P. J. Day, Linux Kernel Mailing List, Andrew Morton, Adrian Bunk

On Sun, Mar 18, 2007 at 04:57:57PM +0100, Andi Kleen wrote:
 > "Robert P. J. Day" <rpjday@mindspring.com> writes:
 > 
 > > Delete the allegedly obsolete raw driver feature, which has been
 > > marked for death since 2005.
 > 
 > I think it would be better to replace it with a wrapper
 > that forces O_DIRECT and opens the underlying block device.  I suspect 
 > just dropping it will break many people's database setups, which is not
 > nice.  Widely used admin interfaces should be only broken when 
 > there is a very good reason and just "there is a better way now" 
 > doesn't seem quite strong enough.

Agreed.  Given how this keeps coming up every few months, lets just
remove that from the list..  It's not that a 306 line driver is
particularly invasive anyways..

Signed-off-by: Dave Jones <davej@redhat.com>

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 0bc8b0b..6b845f3 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -21,14 +21,6 @@ Who:	Pavel Machek <pavel@suse.cz>
 
 ---------------------------
 
-What:	RAW driver (CONFIG_RAW_DRIVER)
-When:	December 2005
-Why:	declared obsolete since kernel 2.6.3
-	O_DIRECT can be used instead
-Who:	Adrian Bunk <bunk@stusta.de>
-
----------------------------
-
 What:	raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
 When:	June 2007
 Why:	Deprecated in favour of the more efficient and robust rawiso interface.


-- 
http://www.codemonkey.org.uk

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-20 16:57   ` Dave Jones
@ 2007-03-20 18:14     ` Alan Cox
  2007-03-20 18:47       ` Robert P. J. Day
  2007-03-21 22:19       ` Andrew Morton
  0 siblings, 2 replies; 21+ messages in thread
From: Alan Cox @ 2007-03-20 18:14 UTC (permalink / raw)
  To: Dave Jones
  Cc: Andi Kleen, Robert P. J. Day, Linux Kernel Mailing List,
	Andrew Morton, Adrian Bunk

On Tue, 20 Mar 2007 12:57:36 -0400
Dave Jones <davej@redhat.com> wrote:

> On Sun, Mar 18, 2007 at 04:57:57PM +0100, Andi Kleen wrote:
>  > "Robert P. J. Day" <rpjday@mindspring.com> writes:
>  > 
>  > > Delete the allegedly obsolete raw driver feature, which has been
>  > > marked for death since 2005.
>  > 
>  > I think it would be better to replace it with a wrapper
>  > that forces O_DIRECT and opens the underlying block device.  I suspect 
>  > just dropping it will break many people's database setups, which is not
>  > nice.  Widely used admin interfaces should be only broken when 
>  > there is a very good reason and just "there is a better way now" 
>  > doesn't seem quite strong enough.
> 
> Agreed.  Given how this keeps coming up every few months, lets just
> remove that from the list..  It's not that a 306 line driver is
> particularly invasive anyways..
> 
> Signed-off-by: Dave Jones <davej@redhat.com>

Acked-by: Alan Cox <alan@redhat.com>

This is a user visible API it is therefore not elligable for removal
anyway

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-20 18:14     ` Alan Cox
@ 2007-03-20 18:47       ` Robert P. J. Day
  2007-03-21 22:19       ` Andrew Morton
  1 sibling, 0 replies; 21+ messages in thread
From: Robert P. J. Day @ 2007-03-20 18:47 UTC (permalink / raw)
  To: Alan Cox
  Cc: Dave Jones, Andi Kleen, Linux Kernel Mailing List, Andrew Morton,
	Adrian Bunk

On Tue, 20 Mar 2007, Alan Cox wrote:

> On Tue, 20 Mar 2007 12:57:36 -0400
> Dave Jones <davej@redhat.com> wrote:
>
> > On Sun, Mar 18, 2007 at 04:57:57PM +0100, Andi Kleen wrote:
> >  > "Robert P. J. Day" <rpjday@mindspring.com> writes:
> >  >
> >  > > Delete the allegedly obsolete raw driver feature, which has been
> >  > > marked for death since 2005.
> >  >
> >  > I think it would be better to replace it with a wrapper
> >  > that forces O_DIRECT and opens the underlying block device.  I suspect
> >  > just dropping it will break many people's database setups, which is not
> >  > nice.  Widely used admin interfaces should be only broken when
> >  > there is a very good reason and just "there is a better way now"
> >  > doesn't seem quite strong enough.
> >
> > Agreed.  Given how this keeps coming up every few months, lets just
> > remove that from the list..  It's not that a 306 line driver is
> > particularly invasive anyways..
> >
> > Signed-off-by: Dave Jones <davej@redhat.com>
>
> Acked-by: Alan Cox <alan@redhat.com>
>
> This is a user visible API it is therefore not elligable for removal
> anyway

great, now i can stop whining about it.  :-)

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-20 18:14     ` Alan Cox
  2007-03-20 18:47       ` Robert P. J. Day
@ 2007-03-21 22:19       ` Andrew Morton
  2007-03-21 23:19         ` Dave Jones
  2007-03-22  0:10         ` Alan Cox
  1 sibling, 2 replies; 21+ messages in thread
From: Andrew Morton @ 2007-03-21 22:19 UTC (permalink / raw)
  To: Alan Cox
  Cc: Dave Jones, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Tue, 20 Mar 2007 18:14:42 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Tue, 20 Mar 2007 12:57:36 -0400
> Dave Jones <davej@redhat.com> wrote:
> 
> > On Sun, Mar 18, 2007 at 04:57:57PM +0100, Andi Kleen wrote:
> >  > "Robert P. J. Day" <rpjday@mindspring.com> writes:
> >  > 
> >  > > Delete the allegedly obsolete raw driver feature, which has been
> >  > > marked for death since 2005.
> >  > 
> >  > I think it would be better to replace it with a wrapper
> >  > that forces O_DIRECT and opens the underlying block device.  I suspect 
> >  > just dropping it will break many people's database setups, which is not
> >  > nice.  Widely used admin interfaces should be only broken when 
> >  > there is a very good reason and just "there is a better way now" 
> >  > doesn't seem quite strong enough.
> > 
> > Agreed.  Given how this keeps coming up every few months, lets just
> > remove that from the list..  It's not that a 306 line driver is
> > particularly invasive anyways..
> > 
> > Signed-off-by: Dave Jones <davej@redhat.com>
> 
> Acked-by: Alan Cox <alan@redhat.com>
> 
> This is a user visible API it is therefore not elligable for removal
> anyway

mutter.

We've given people years of notice and _some_ applications have converted
over to open("/dev/sda1", O_DIRECT), as they should.

Sure, it's a small and simple driver (now), so the cost of maintaining it
is low.

But otoh, there's no reason for it to exist, except for userspace
sluggishness.

So we can either give up, or we can push on: put a rude printk in there
somewhere and who knows, maybe in five years time we can finally be rid of
the thing.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  0:10         ` Alan Cox
@ 2007-03-21 23:13           ` Andrew Morton
  2007-03-21 23:24             ` Willy Tarreau
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2007-03-21 23:13 UTC (permalink / raw)
  To: Alan Cox
  Cc: Dave Jones, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, 22 Mar 2007 00:10:50 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > > This is a user visible API it is therefore not elligable for removal
> > > anyway
> > 
> > mutter.
> > 
> > We've given people years of notice and _some_ applications have converted
> > over to open("/dev/sda1", O_DIRECT), as they should.
> 
> Linus said we don't break old applications by removing APIs. People
> believe him. 
> 

That's just dogma, and not credible dogma at that.  We regularly remove
features and we have processes for this.

There is no reason why we cannot, with sufficient effort, remove this
driver at some time in the future.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 22:19       ` Andrew Morton
@ 2007-03-21 23:19         ` Dave Jones
  2007-03-21 23:27           ` Andrew Morton
  2007-03-22  0:10         ` Alan Cox
  1 sibling, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-21 23:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Wed, Mar 21, 2007 at 03:19:52PM -0700, Andrew Morton wrote:

 > We've given people years of notice and _some_ applications have converted
 > over to open("/dev/sda1", O_DIRECT), as they should.
 > 
 > Sure, it's a small and simple driver (now), so the cost of maintaining it
 > is low.
 > 
 > But otoh, there's no reason for it to exist, except for userspace
 > sluggishness.
 > 
 > So we can either give up, or we can push on: put a rude printk in there
 > somewhere and who knows, maybe in five years time we can finally be rid of
 > the thing.

We've actually tried to deprecate this twice. First in RHEL4, and more
recently in RHEL5.  The conversations go something like this..

Customer: app xyz doesn't work.
Us: it's using a deprecated API, it needs to be updated to use O_DIRECT
Customer: vendor says "pay us $$$$$ to go to version N+1"

Then we find out the customer can't move to N+1 because they have
some other piece of infrastructure that relies on semantics in the
old version, and screaming and hairpulling ensues.

(And this is one of the more promising conversations. Others
 that have happened with certain db vendors are enough to
 make the pope curse).

Adding printk's on open() of it doesn't solve the problem either.
The people that see them are the customers who run this stuff,
not the people who have the ability to change the code.

If it gets dropped from kernel.org, it wouldn't be long before
it'd find its way back into enterprise vendor kernels.
Isn't it better that we all at least ship the same thing? [1]

	Dave

[1] Though admittedly the one in RHEL deviates from upstream
as it contains performance enhancements that were vetoed from
upstream acceptance due to it being "deprecated".

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:13           ` Andrew Morton
@ 2007-03-21 23:24             ` Willy Tarreau
  2007-03-21 23:43               ` Dave Jones
  0 siblings, 1 reply; 21+ messages in thread
From: Willy Tarreau @ 2007-03-21 23:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alan Cox, Dave Jones, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Wed, Mar 21, 2007 at 04:13:41PM -0700, Andrew Morton wrote:
> On Thu, 22 Mar 2007 00:10:50 +0000
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > > > This is a user visible API it is therefore not elligable for removal
> > > > anyway
> > > 
> > > mutter.
> > > 
> > > We've given people years of notice and _some_ applications have converted
> > > over to open("/dev/sda1", O_DIRECT), as they should.
> > 
> > Linus said we don't break old applications by removing APIs. People
> > believe him. 
> > 
> 
> That's just dogma, and not credible dogma at that.  We regularly remove
> features and we have processes for this.
> 
> There is no reason why we cannot, with sufficient effort, remove this
> driver at some time in the future.

Then a printk() on every open() should be enough. We've all been seeing
"Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
It's a slow but necessary process IMHO. I agree with Alan that it's not
nice for the users to have sudden application errors without enough earlier
notification (not everybody reads sources for removal notifications).

Regards,
Willy


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:19         ` Dave Jones
@ 2007-03-21 23:27           ` Andrew Morton
  2007-03-21 23:42             ` Dave Jones
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2007-03-21 23:27 UTC (permalink / raw)
  To: Dave Jones
  Cc: Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Wed, 21 Mar 2007 19:19:35 -0400
Dave Jones <davej@redhat.com> wrote:

> On Wed, Mar 21, 2007 at 03:19:52PM -0700, Andrew Morton wrote:
> 
>  > We've given people years of notice and _some_ applications have converted
>  > over to open("/dev/sda1", O_DIRECT), as they should.
>  > 
>  > Sure, it's a small and simple driver (now), so the cost of maintaining it
>  > is low.
>  > 
>  > But otoh, there's no reason for it to exist, except for userspace
>  > sluggishness.
>  > 
>  > So we can either give up, or we can push on: put a rude printk in there
>  > somewhere and who knows, maybe in five years time we can finally be rid of
>  > the thing.
> 
> We've actually tried to deprecate this twice. First in RHEL4, and more
> recently in RHEL5.  The conversations go something like this..
> 
> Customer: app xyz doesn't work.
> Us: it's using a deprecated API, it needs to be updated to use O_DIRECT
> Customer: vendor says "pay us $$$$$ to go to version N+1"
> 
> Then we find out the customer can't move to N+1 because they have
> some other piece of infrastructure that relies on semantics in the
> old version, and screaming and hairpulling ensues.
> 
> (And this is one of the more promising conversations. Others
>  that have happened with certain db vendors are enough to
>  make the pope curse).
> 
> Adding printk's on open() of it doesn't solve the problem either.
> The people that see them are the customers who run this stuff,
> not the people who have the ability to change the code.
> 
> If it gets dropped from kernel.org, it wouldn't be long before
> it'd find its way back into enterprise vendor kernels.
> Isn't it better that we all at least ship the same thing? [1]
> 

Yes, I realise it's a tough thing to do - large vendors of large databases
aren't the most agile or clueful of organisations.

If it's your assessment that it's just unreasonsable for us to expect that
we'll ever be able to be rid of the thing then ho hum I guess we might as
well give up.

It's a pretty sad situation though.

> 
> [1] Though admittedly the one in RHEL deviates from upstream
> as it contains performance enhancements that were vetoed from
> upstream acceptance due to it being "deprecated".

What enhancements are they?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:27           ` Andrew Morton
@ 2007-03-21 23:42             ` Dave Jones
  2007-03-21 23:56               ` Andrew Morton
  0 siblings, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-21 23:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Wed, Mar 21, 2007 at 04:27:17PM -0700, Andrew Morton wrote:
 > > [1] Though admittedly the one in RHEL deviates from upstream
 > > as it contains performance enhancements that were vetoed from
 > > upstream acceptance due to it being "deprecated".
 > 
 > What enhancements are they?

Hmm, actually it seems I was mistaken, we didn't merge those after all,
we seem to be shipping what was upstream in 2.6.9/2.6.18.

The patches I was thinking of were a bunch of optimisations for higher
throughput from someone at Intel iirc. Ken Chen maybe?

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:24             ` Willy Tarreau
@ 2007-03-21 23:43               ` Dave Jones
  2007-03-22  4:12                 ` Willy Tarreau
  0 siblings, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-21 23:43 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Andrew Morton, Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
 
 > Then a printk() on every open() should be enough. We've all been seeing
 > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.

There's a difference.  We have the source for tcpdump.

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:42             ` Dave Jones
@ 2007-03-21 23:56               ` Andrew Morton
  0 siblings, 0 replies; 21+ messages in thread
From: Andrew Morton @ 2007-03-21 23:56 UTC (permalink / raw)
  To: Dave Jones
  Cc: Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Wed, 21 Mar 2007 19:42:36 -0400
Dave Jones <davej@redhat.com> wrote:

> On Wed, Mar 21, 2007 at 04:27:17PM -0700, Andrew Morton wrote:
>  > > [1] Though admittedly the one in RHEL deviates from upstream
>  > > as it contains performance enhancements that were vetoed from
>  > > upstream acceptance due to it being "deprecated".
>  > 
>  > What enhancements are they?
> 
> Hmm, actually it seems I was mistaken, we didn't merge those after all,
> we seem to be shipping what was upstream in 2.6.9/2.6.18.
> 
> The patches I was thinking of were a bunch of optimisations for higher
> throughput from someone at Intel iirc. Ken Chen maybe?

Ah, OK.

Ken had an initial set of patches which weren't very popular.  Months
later, he had a second set which did get merged into mainline, but they
broke, so that code is presently mucking up fs/block_dev.c, inside #if 0,
awaiting possible repair.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 22:19       ` Andrew Morton
  2007-03-21 23:19         ` Dave Jones
@ 2007-03-22  0:10         ` Alan Cox
  2007-03-21 23:13           ` Andrew Morton
  1 sibling, 1 reply; 21+ messages in thread
From: Alan Cox @ 2007-03-22  0:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Dave Jones, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

> > This is a user visible API it is therefore not elligable for removal
> > anyway
> 
> mutter.
> 
> We've given people years of notice and _some_ applications have converted
> over to open("/dev/sda1", O_DIRECT), as they should.

Linus said we don't break old applications by removing APIs. People
believe him. 

Alan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-21 23:43               ` Dave Jones
@ 2007-03-22  4:12                 ` Willy Tarreau
  2007-03-22  4:17                   ` Dave Jones
  0 siblings, 1 reply; 21+ messages in thread
From: Willy Tarreau @ 2007-03-22  4:12 UTC (permalink / raw)
  To: Dave Jones, Andrew Morton, Alan Cox, Andi Kleen,
	Robert P. J. Day, Linux Kernel Mailing List, Adrian Bunk

On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
> On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
>  
>  > Then a printk() on every open() should be enough. We've all been seeing
>  > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
> 
> There's a difference.  We have the source for tcpdump.

But what's the problem with "warning: process XXX uses obsolete raw driver
and may not work anymore after 2007/XX/XX if not fixed" ?

Willy


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  4:12                 ` Willy Tarreau
@ 2007-03-22  4:17                   ` Dave Jones
  2007-03-22  4:45                     ` Willy Tarreau
  0 siblings, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-22  4:17 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Andrew Morton, Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
 > On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
 > > On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
 > >  
 > >  > Then a printk() on every open() should be enough. We've all been seeing
 > >  > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
 > > 
 > > There's a difference.  We have the source for tcpdump.
 > 
 > But what's the problem with "warning: process XXX uses obsolete raw driver
 > and may not work anymore after 2007/XX/XX if not fixed" ?

The target audience isn't going to read it.

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  4:17                   ` Dave Jones
@ 2007-03-22  4:45                     ` Willy Tarreau
  2007-03-22  5:02                       ` Dave Jones
  0 siblings, 1 reply; 21+ messages in thread
From: Willy Tarreau @ 2007-03-22  4:45 UTC (permalink / raw)
  To: Dave Jones, Andrew Morton, Alan Cox, Andi Kleen,
	Robert P. J. Day, Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 12:17:51AM -0400, Dave Jones wrote:
> On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
>  > On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
>  > > On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
>  > >  
>  > >  > Then a printk() on every open() should be enough. We've all been seeing
>  > >  > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
>  > > 
>  > > There's a difference.  We have the source for tcpdump.
>  > 
>  > But what's the problem with "warning: process XXX uses obsolete raw driver
>  > and may not work anymore after 2007/XX/XX if not fixed" ?
> 
> The target audience isn't going to read it.

Yes they will if you write it with KERN_CRIT. It will show up on all their
consoles every time their process starts up. What is right is that those
people preferably use vendors' distro and generally do not compile their
kernels themselves, unless there are internal skills and good motivation
to do so.

Willy


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  4:45                     ` Willy Tarreau
@ 2007-03-22  5:02                       ` Dave Jones
  2007-03-22  5:53                         ` Willy Tarreau
  0 siblings, 1 reply; 21+ messages in thread
From: Dave Jones @ 2007-03-22  5:02 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Andrew Morton, Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 05:45:40AM +0100, Willy Tarreau wrote:
 > On Thu, Mar 22, 2007 at 12:17:51AM -0400, Dave Jones wrote:
 > > On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
 > >  > On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
 > >  > > On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
 > >  > >  
 > >  > >  > Then a printk() on every open() should be enough. We've all been seeing
 > >  > >  > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
 > >  > > 
 > >  > > There's a difference.  We have the source for tcpdump.
 > >  > 
 > >  > But what's the problem with "warning: process XXX uses obsolete raw driver
 > >  > and may not work anymore after 2007/XX/XX if not fixed" ?
 > > 
 > > The target audience isn't going to read it.
 > 
 > Yes they will if you write it with KERN_CRIT.

*no*.

Users will see it. The developers of the software those users are running won't.
We're talking about apps here that we don't have the source to, and vendors
want extortionate amount of money to change.

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  5:02                       ` Dave Jones
@ 2007-03-22  5:53                         ` Willy Tarreau
  2007-03-22  6:10                           ` Dave Jones
  0 siblings, 1 reply; 21+ messages in thread
From: Willy Tarreau @ 2007-03-22  5:53 UTC (permalink / raw)
  To: Dave Jones, Andrew Morton, Alan Cox, Andi Kleen,
	Robert P. J. Day, Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 01:02:50AM -0400, Dave Jones wrote:
> On Thu, Mar 22, 2007 at 05:45:40AM +0100, Willy Tarreau wrote:
>  > On Thu, Mar 22, 2007 at 12:17:51AM -0400, Dave Jones wrote:
>  > > On Thu, Mar 22, 2007 at 05:12:42AM +0100, Willy Tarreau wrote:
>  > >  > On Wed, Mar 21, 2007 at 07:43:18PM -0400, Dave Jones wrote:
>  > >  > > On Thu, Mar 22, 2007 at 12:24:33AM +0100, Willy Tarreau wrote:
>  > >  > >  
>  > >  > >  > Then a printk() on every open() should be enough. We've all been seeing
>  > >  > >  > "Warning: tcpdump uses obsolete AF_PACKET"... and it finally disappeared.
>  > >  > > 
>  > >  > > There's a difference.  We have the source for tcpdump.
>  > >  > 
>  > >  > But what's the problem with "warning: process XXX uses obsolete raw driver
>  > >  > and may not work anymore after 2007/XX/XX if not fixed" ?
>  > > 
>  > > The target audience isn't going to read it.
>  > 
>  > Yes they will if you write it with KERN_CRIT.
> 
> *no*.
> 
> Users will see it. The developers of the software those users are running won't.
> We're talking about apps here that we don't have the source to, and vendors
> want extortionate amount of money to change.

Dave, I think you don't get it. People are paying to run those apps. When
you pay 10s or 100s of K$ a year for support and you see such messages
appear in your logs, you ask the app vendor what will happen at the given
date. Those people are already afraid by end of support on products without
any warning message. I sincerely believe that they will insist even more
when the message tells them about the end of compatibility date.

Of course, the vendor will say "we've been informed that this is caused by
a change in distro XXX. Distro YYY does not have it, you may want to migrate".
But those responses rarely satisfy customers who have to revalidate everything
to change a distro.

At most, they will ask their distro vendor for continued support of the
feature (which there will be in the same minor release), and if vendors'
feedback show there is enough demand, then we will just have to delay the
removal.

Regards,
Willy


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] Delete obsolete RAW driver feature.
  2007-03-22  5:53                         ` Willy Tarreau
@ 2007-03-22  6:10                           ` Dave Jones
  0 siblings, 0 replies; 21+ messages in thread
From: Dave Jones @ 2007-03-22  6:10 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Andrew Morton, Alan Cox, Andi Kleen, Robert P. J. Day,
	Linux Kernel Mailing List, Adrian Bunk

On Thu, Mar 22, 2007 at 06:53:06AM +0100, Willy Tarreau wrote:

 > At most, they will ask their distro vendor for continued support of the
 > feature (which there will be in the same minor release), and if vendors'
 > feedback show there is enough demand, then we will just have to delay the
 > removal.

Err, this is where we are _today_

	Dave

-- 
http://www.codemonkey.org.uk

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2007-03-22  6:12 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-18 11:59 [PATCH] Delete obsolete RAW driver feature Robert P. J. Day
2007-03-18 15:57 ` Andi Kleen
2007-03-18 15:38   ` Robert P. J. Day
2007-03-20 16:57   ` Dave Jones
2007-03-20 18:14     ` Alan Cox
2007-03-20 18:47       ` Robert P. J. Day
2007-03-21 22:19       ` Andrew Morton
2007-03-21 23:19         ` Dave Jones
2007-03-21 23:27           ` Andrew Morton
2007-03-21 23:42             ` Dave Jones
2007-03-21 23:56               ` Andrew Morton
2007-03-22  0:10         ` Alan Cox
2007-03-21 23:13           ` Andrew Morton
2007-03-21 23:24             ` Willy Tarreau
2007-03-21 23:43               ` Dave Jones
2007-03-22  4:12                 ` Willy Tarreau
2007-03-22  4:17                   ` Dave Jones
2007-03-22  4:45                     ` Willy Tarreau
2007-03-22  5:02                       ` Dave Jones
2007-03-22  5:53                         ` Willy Tarreau
2007-03-22  6:10                           ` Dave Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).