Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
Signed-off-by: Adrian Bunk <[email protected]>
---
Documentation/feature-removal-schedule.txt | 8
Documentation/ioctl-mess.txt | 8
drivers/char/Kconfig | 20 -
drivers/char/Makefile | 1
drivers/char/mem.c | 1
drivers/char/raw.c | 343 ---------------------
fs/compat_ioctl.c | 69 ----
include/linux/compat_ioctl.h | 3
include/linux/raw.h | 18 -
9 files changed, 471 deletions(-)
--- linux-2.6.16-rc1-mm1-full/Documentation/feature-removal-schedule.txt.old 2006-01-19 03:29:57.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/Documentation/feature-removal-schedule.txt 2006-01-19 03:30:03.000000000 +0100
@@ -20,8 +19,0 @@
-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 <[email protected]>
-
----------------------------
-
--- linux-2.6.16-rc1-mm1-full/drivers/char/Kconfig.old 2006-01-19 03:30:43.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/Kconfig 2006-01-19 03:31:11.000000000 +0100
@@ -939,26 +939,6 @@
tristate "NEC VR4100 series General-purpose I/O Unit support"
depends on CPU_VR41XX
-config RAW_DRIVER
- tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
- 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
--- linux-2.6.16-rc1-mm1-full/drivers/char/Makefile.old 2006-01-19 03:32:11.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/Makefile 2006-01-19 03:32:16.000000000 +0100
@@ -42,7 +42,6 @@
obj-$(CONFIG_SX) += sx.o generic_serial.o
obj-$(CONFIG_RIO) += rio/ generic_serial.o
obj-$(CONFIG_HVC_CONSOLE) += hvc_console.o hvc_vio.o hvsi.o
-obj-$(CONFIG_RAW_DRIVER) += raw.o
obj-$(CONFIG_SGI_SNSC) += snsc.o snsc_event.o
obj-$(CONFIG_MMTIMER) += mmtimer.o
obj-$(CONFIG_VIOCONS) += viocons.o
--- linux-2.6.16-rc1-mm1-full/drivers/char/mem.c.old 2006-01-19 03:32:41.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/mem.c 2006-01-19 03:32:50.000000000 +0100
@@ -16,7 +16,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>
--- linux-2.6.16-rc1-mm1-full/include/linux/compat_ioctl.h.old 2006-01-19 03:34:12.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/include/linux/compat_ioctl.h 2006-01-19 03:34:17.000000000 +0100
@@ -568,9 +568,6 @@
COMPATIBLE_IOCTL(DEVFSDIOC_SET_EVENT_MASK)
COMPATIBLE_IOCTL(DEVFSDIOC_RELEASE_EVENT_QUEUE)
COMPATIBLE_IOCTL(DEVFSDIOC_SET_DEBUG_MASK)
-/* Raw devices */
-COMPATIBLE_IOCTL(RAW_SETBIND)
-COMPATIBLE_IOCTL(RAW_GETBIND)
/* SMB ioctls which do not need any translations */
COMPATIBLE_IOCTL(SMB_IOC_NEWCONN)
/* NCP ioctls which do not need any translations */
--- linux-2.6.16-rc1-mm1-full/fs/compat_ioctl.c.old 2006-01-19 03:32:58.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/fs/compat_ioctl.c 2006-01-19 03:33:25.000000000 +0100
@@ -53,7 +53,6 @@
#include <linux/ext3_fs.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>
@@ -2141,71 +2140,6 @@
return sys_ioctl(fd,cmd,ptr);
}
-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;
-}
-
struct serial_struct32 {
compat_int_t type;
compat_int_t line;
@@ -2913,9 +2847,6 @@
HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
HANDLE_IOCTL(REISERFS_IOC_UNPACK32, reiserfs_ioctl32)
-/* Raw devices */
-HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
-HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
/* Serial */
HANDLE_IOCTL(TIOCGSERIAL, serial_struct_ioctl)
HANDLE_IOCTL(TIOCSSERIAL, serial_struct_ioctl)
--- linux-2.6.16-rc1-mm1-full/Documentation/ioctl-mess.txt.old 2006-01-19 03:33:44.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/Documentation/ioctl-mess.txt 2006-01-19 03:33:57.000000000 +0100
@@ -3385,14 +3385,6 @@
I: -
O: struct mdu_version_s
-N: RAW_GETBIND
-I: struct raw_config_request
-O: struct raw_config_request
-
-N: RAW_SETBIND
-I: struct raw_config_request
-O: -
-
REISERFS_IOC_UNPACK32
N: RESTART_ARRAY_RW
--- linux-2.6.16-rc1-mm1-full/include/linux/raw.h 2006-01-03 04:21:10.000000000 +0100
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -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 */
--- linux-2.6.16-rc1-mm1-full/drivers/char/raw.c 2006-01-18 20:21:53.000000000 +0100
+++ /dev/null 2005-11-08 19:07:57.000000000 +0100
@@ -1,343 +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/devfs_fs_kernel.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 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_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)
-{
- class_device_destroy(raw_class, MKDEV(RAW_MAJOR, rq->raw_minor));
- class_device_create(raw_class, NULL, MKDEV(RAW_MAJOR, rq->raw_minor),
- NULL, "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;
- class_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 ssize_t raw_file_write(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct iovec local_iov = {
- .iov_base = (char __user *)buf,
- .iov_len = count
- };
-
- return generic_file_write_nolock(file, &local_iov, 1, ppos);
-}
-
-static ssize_t raw_file_aio_write(struct kiocb *iocb, const char __user *buf,
- size_t count, loff_t pos)
-{
- struct iovec local_iov = {
- .iov_base = (char __user *)buf,
- .iov_len = count
- };
-
- return generic_file_aio_write_nolock(iocb, &local_iov, 1, &iocb->ki_pos);
-}
-
-
-static struct file_operations raw_fops = {
- .read = generic_file_read,
- .aio_read = generic_file_aio_read,
- .write = raw_file_write,
- .aio_write = raw_file_aio_write,
- .open = raw_open,
- .release= raw_release,
- .ioctl = raw_ioctl,
- .readv = generic_file_readv,
- .writev = generic_file_writev,
- .owner = THIS_MODULE,
-};
-
-static 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)
-{
- int i;
- dev_t dev = MKDEV(RAW_MAJOR, 0);
-
- if (register_chrdev_region(dev, MAX_RAW_MINORS, "raw"))
- goto error;
-
- cdev_init(&raw_cdev, &raw_fops);
- if (cdev_add(&raw_cdev, dev, MAX_RAW_MINORS)) {
- kobject_put(&raw_cdev.kobj);
- unregister_chrdev_region(dev, MAX_RAW_MINORS);
- goto error;
- }
-
- raw_class = class_create(THIS_MODULE, "raw");
- if (IS_ERR(raw_class)) {
- printk(KERN_ERR "Error creating raw class.\n");
- cdev_del(&raw_cdev);
- unregister_chrdev_region(dev, MAX_RAW_MINORS);
- goto error;
- }
- class_device_create(raw_class, NULL, MKDEV(RAW_MAJOR, 0), NULL, "rawctl");
-
- devfs_mk_cdev(MKDEV(RAW_MAJOR, 0),
- S_IFCHR | S_IRUGO | S_IWUGO,
- "raw/rawctl");
- for (i = 1; i < MAX_RAW_MINORS; i++)
- devfs_mk_cdev(MKDEV(RAW_MAJOR, i),
- S_IFCHR | S_IRUGO | S_IWUGO,
- "raw/raw%d", i);
- return 0;
-
-error:
- printk(KERN_ERR "error register raw device\n");
- return 1;
-}
-
-static void __exit raw_exit(void)
-{
- int i;
-
- for (i = 1; i < MAX_RAW_MINORS; i++)
- devfs_remove("raw/raw%d", i);
- devfs_remove("raw/rawctl");
- devfs_remove("raw");
- class_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");
Adrian Bunk <[email protected]> wrote:
>
> Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
>
heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
I doubt if this'll fly. We're stuck with it.
Andrew Morton wrote on Wednesday, January 18, 2006 7:41 PM
> Adrian Bunk <[email protected]> wrote:
> >
> > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> >
>
> heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
>
> I doubt if this'll fly. We're stuck with it.
Could we please, leave the raw device driver alone. ISV is doing
their diligent work converting new code to O_DIRECT, but large amount
of field customers are still using raw device in their setup.
- Ken
On Wed, Jan 18, 2006 at 07:41:03PM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> >
>
> heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
>
> I doubt if this'll fly. We're stuck with it.
Why is the person listed in Documentation/feature-removal-schedule.txt
the last one to hear that someone still requires something scheduled for
removal?
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
On Wed, 2006-01-18 at 19:41 -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> >
>
> heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
>
> I doubt if this'll fly. We're stuck with it.
>From the customer perspective, it would be nice to have "raw", since
they are used to it.
Now, putting on my "community hat" - we gave enough notice about the
removal. Few major distro releases happend after that. So, I am not
really going to complain - if it goes away.
But again, its really useful to have raw driver to do simple "dd" tests
to test raw performance for disks (for comparing with filesystems, block
devices etc..). Without that, we need to add option to "dd" for
O_DIRECT.
Thanks,
Badari
Badari Pulavarty wrote:
>
> But again, its really useful to have raw driver to do simple "dd" tests
> to test raw performance for disks (for comparing with filesystems, block
> devices etc..). Without that, we need to add option to "dd" for
> O_DIRECT.
Perhaps it's time for 'dd' to acquire something like the 'hdparm --direct' flag.
(and, oops, maybe I should add it to the man page for hdparm too!).
Cheers
On Thu, Jan 19, 2006 at 08:44:31AM -0800, Badari Pulavarty wrote:
>...
> But again, its really useful to have raw driver to do simple "dd" tests
> to test raw performance for disks (for comparing with filesystems, block
> devices etc..). Without that, we need to add option to "dd" for
> O_DIRECT.
The oflag=direct option was added to GNU coreutils in version 5.3.0.
> Thanks,
> Badari
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
On Thu, 2006-01-19 at 17:58 +0100, Adrian Bunk wrote:
> On Thu, Jan 19, 2006 at 08:44:31AM -0800, Badari Pulavarty wrote:
> >...
> > But again, its really useful to have raw driver to do simple "dd" tests
> > to test raw performance for disks (for comparing with filesystems, block
> > devices etc..). Without that, we need to add option to "dd" for
> > O_DIRECT.
>
> The oflag=direct option was added to GNU coreutils in version 5.3.0.
Cool. It works - I have no complaints, then :)
# dd if=/dev/sda iflag=direct of=/dev/null bs=64k
Thanks,
Badari
On Thursday 19 January 2006 17:58, Adrian Bunk wrote:
> On Thu, Jan 19, 2006 at 08:44:31AM -0800, Badari Pulavarty wrote:
> >...
> > But again, its really useful to have raw driver to do simple "dd" tests
> > to test raw performance for disks (for comparing with filesystems, block
> > devices etc..). Without that, we need to add option to "dd" for
> > O_DIRECT.
>
> The oflag=direct option was added to GNU coreutils in version 5.3.0.
And Debian Sarge is still at 5.2.1.
(Not to obsolete iproute and ipsec-tools versions)
Ok, Debian Sarge is scheduled for removal from my
system.
What: Debian Sarge
When: 2006-02-04
Files: ssh root@bertha -c "find /bin /sbin /usr /lib"
Why: Its maintained to slow for a number of years
and can be replaced by Kubuntu or Ubuntu.
Having a recent kernel (with more bugs fixed)
and trying to use it, becomes harder and harder.
Who: $FROM
>Ok, Debian Sarge is scheduled for removal from my
>system.
>
>What: Debian Sarge
>When: 2006-02-04
>Files: ssh root@bertha -c "find /bin /sbin /usr /lib"
>
>Why: Its maintained to slow for a number of years
> and can be replaced by Kubuntu or Ubuntu.
> Having a recent kernel (with more bugs fixed)
> and trying to use it, becomes harder and harder.
I really don't want to make an ad for suse, but they are also having a
"releaseless" distro (i.e. update when it comes && the rpm maintainer feels
like doing it), the "SL-OSS-factory".
Jan Engelhardt
--
On Wed, Jan 18, 2006 at 09:43:12PM -0800, Chen, Kenneth W wrote:
> Andrew Morton wrote on Wednesday, January 18, 2006 7:41 PM
> > Adrian Bunk <[email protected]> wrote:
> > >
> > > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> > >
> >
> > heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
> >
> > I doubt if this'll fly. We're stuck with it.
>
>
> Could we please, leave the raw device driver alone. ISV is doing
> their diligent work converting new code to O_DIRECT, but large amount
> of field customers are still using raw device in their setup.
Why did noone tell me anythong about such issues although I'm the one
listed as having this driver deprecated?
Is our feature removal process completely busted?
And WTF is ISV?
> - Ken
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
Adrian Bunk wrote on Friday, January 20, 2006 5:02 PM
> Why did noone tell me anythong about such issues although I'm the one
> listed as having this driver deprecated?
> Is our feature removal process completely busted?
Now that you know about it, you should remove yourself from deprecating
the driver and leave it alone.
> And WTF is ISV?
Independent Software Vendor.
- Ken
On Sad, 2006-01-21 at 02:02 +0100, Adrian Bunk wrote:
> Why did noone tell me anythong about such issues although I'm the one
> listed as having this driver deprecated?
Because they don't spend their lives tracking the base kernel, they
expect sanity to prevail and their idea of an obsolescence cycle is
about five years.
ISV = "Independant software vendor"
Obsoleting stuff which is distribution internal configuration type stuff
(eg devfs->udev) is one thing but core syscall related stuff has to
undergo a much much longer cycle, or in many cases you just have to look
at it and treat it as a lesson for the future and a thing to tackle in
whatever OS obsoletes Linux.
Thats why 0.98.5 libc 2.2 and rogue still work on 2.6.
Alan
On Wed, 2006-01-18 at 19:41 -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> >
>
> heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
>
> I doubt if this'll fly. We're stuck with it.
One thing we can do is ask the distributions to stop shipping raw first,
to see what the fallout is (and to give it as a sign that it's an
obsolete interface). Then a year or two after that....
On Sat, Jan 21, 2006 at 09:52:27AM +0100, Arjan van de Ven wrote:
> On Wed, 2006-01-18 at 19:41 -0800, Andrew Morton wrote:
> > Adrian Bunk <[email protected]> wrote:
> > >
> > > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> > >
> >
> > heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
> >
> > I doubt if this'll fly. We're stuck with it.
>
> One thing we can do is ask the distributions to stop shipping raw first,
> to see what the fallout is (and to give it as a sign that it's an
> obsolete interface). Then a year or two after that....
It's been off in Fedora since FC4.
RHEL4 had it enabled after several vendors complained a lot about its
absense breaking an installed userbase, though they were told it would be
enabled with the proviso that it would go away in the future.
RHEL5 isn't even in beta yet, but I can already hear the voices asking
for it be reenabled..
Dave
Dave Jones <[email protected]> wrote:
>
> On Sat, Jan 21, 2006 at 09:52:27AM +0100, Arjan van de Ven wrote:
> > On Wed, 2006-01-18 at 19:41 -0800, Andrew Morton wrote:
> > > Adrian Bunk <[email protected]> wrote:
> > > >
> > > > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> > > >
> > >
> > > heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
> > >
> > > I doubt if this'll fly. We're stuck with it.
> >
> > One thing we can do is ask the distributions to stop shipping raw first,
> > to see what the fallout is (and to give it as a sign that it's an
> > obsolete interface). Then a year or two after that....
>
> It's been off in Fedora since FC4.
> RHEL4 had it enabled after several vendors complained a lot about its
> absense breaking an installed userbase, though they were told it would be
> enabled with the proviso that it would go away in the future.
> RHEL5 isn't even in beta yet, but I can already hear the voices asking
> for it be reenabled..
>
Thanks for trying though ;) It's good that RH is helping to push things
along like this - the easiest path would be to turn the thing on and
complain when anyone made noises about taking it out.
On Sat, 2006-01-21 at 13:17 -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> wrote:
> >
> > On Sat, Jan 21, 2006 at 09:52:27AM +0100, Arjan van de Ven wrote:
> > > On Wed, 2006-01-18 at 19:41 -0800, Andrew Morton wrote:
> > > > Adrian Bunk <[email protected]> wrote:
> > > > >
> > > > > Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
> > > > >
> > > >
> > > > heh. I was just thinking that I hadn't heard from Badari and Ken in a while.
> > > >
> > > > I doubt if this'll fly. We're stuck with it.
> > >
> > > One thing we can do is ask the distributions to stop shipping raw first,
> > > to see what the fallout is (and to give it as a sign that it's an
> > > obsolete interface). Then a year or two after that....
> >
> > It's been off in Fedora since FC4.
> > RHEL4 had it enabled after several vendors complained a lot about its
> > absense breaking an installed userbase, though they were told it would be
> > enabled with the proviso that it would go away in the future.
> > RHEL5 isn't even in beta yet, but I can already hear the voices asking
> > for it be reenabled..
> >
>
> Thanks for trying though ;) It's good that RH is helping to push things
> along like this - the easiest path would be to turn the thing on and
> complain when anyone made noises about taking it out.
another thing we really should do is making such "obsolete to be phased
out" things printk (at least once per boot ;) so that people see it in
their logs, not just in the kernel source.
It's really useful to find culprits that way in distros (sometimes
there's apps that do the weirdest things).. but also a good sign to ISVs
that they should start investigating alternatives. Yes that takes a long
time, but that just means it's important to start warning them early...
Arjan van de Ven <[email protected]> wrote:
>
> another thing we really should do is making such "obsolete to be phased
> out" things printk (at least once per boot ;) so that people see it in
> their logs, not just in the kernel source.
Like sys_bdflush() has been doing for 3-4 years. That still comes out on
a few of my test boxes, but I'm a distro recidivist.
On Sat, 2006-01-21 at 13:35 -0800, Andrew Morton wrote:
> Arjan van de Ven <[email protected]> wrote:
> >
> > another thing we really should do is making such "obsolete to be phased
> > out" things printk (at least once per boot ;) so that people see it in
> > their logs, not just in the kernel source.
>
> Like sys_bdflush() has been doing for 3-4 years. That still comes out on
> a few of my test boxes, but I'm a distro recidivist.
so it works ;)
if you were a distro maker or a userland software developer you'd notice
and change (just like non-paleontic distro makers did ;)..
On Wednesday 18 January 2006 22:02, Adrian Bunk wrote:
>Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
This thread has run on for a bit longer it seems, and it prompts me to
back up to the original post and ask if the raw driver you are removing
is the raw driver used when cups tells a device (a printer) to do this
file using the -o raw format?
If this is the case, then a rather large amount of printing
functionality will be removed as a side effect. I hope I'm
miss-understanding the intent here.
[huge snippage]
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sat, 2006-01-21 at 18:26 -0500, Gene Heskett wrote:
> On Wednesday 18 January 2006 22:02, Adrian Bunk wrote:
> >Let's do the scheduled removal of the obsolete raw driver in 2.6.17.
>
> This thread has run on for a bit longer it seems, and it prompts me to
> back up to the original post and ask if the raw driver you are removing
> is the raw driver used when cups tells a device (a printer) to do this
> file using the -o raw format?
>
> If this is the case, then a rather large amount of printing
> functionality will be removed as a side effect. I hope I'm
> miss-understanding the intent here.
No, it's a different raw driver, for big databases that basically want
their own custom filesystem on a disk.
Lee
On Saturday 21 January 2006 18:30, Lee Revell wrote:
>On Sat, 2006-01-21 at 18:26 -0500, Gene Heskett wrote:
>> On Wednesday 18 January 2006 22:02, Adrian Bunk wrote:
>> >Let's do the scheduled removal of the obsolete raw driver in
>> > 2.6.17.
>>
>> This thread has run on for a bit longer it seems, and it prompts me
>> to back up to the original post and ask if the raw driver you are
>> removing is the raw driver used when cups tells a device (a printer)
>> to do this file using the -o raw format?
>>
>> If this is the case, then a rather large amount of printing
>> functionality will be removed as a side effect. I hope I'm
>> miss-understanding the intent here.
>
>No, it's a different raw driver, for big databases that basically want
>their own custom filesystem on a disk.
With the attendent possibility of rendering the whole thing
unrecoverably moot?
OTOH, if this database actually does have a better way, and its mature
and proven, then I see no reason to cripple the database people just to
remove what is viewed as a potentially dangerous path to the media
surface for the unwashed to abuse.
While I'm infinitely familiar with walking around and editing bits and
bytes in a much older filesystem than ext3 (microwares os-9), there's
no way in hell I'd try that where 200GB of data could go byby. A 720k
floppy can always be re-written, but not a truely huge filesystem, nuh
uh unless you have bare metal backups.
But thats just me being a cautious old fart, but some of the database
folks have decades of such experience and shouldn't be penalized for
using what to them is the fastest way to do it, after all, speed is the
very essence of a databases performance. Its what they sell as the
sizzle. Methinks then that rather than give up that advantage, maybe a
newer filesystem might be forthcoming from the db folks, one that
preserves that perceived advantage, but only if that advantage can be
protected from other db vendors being able to use it too. Which would
being up licenseing issues I'm sure, but thats another argument on
another day. Thats why this looks a bit like a lose-lose situation as
it will hurt, rather than enhance, the overall linux performance.
My $0.02, adjust for inflation since 1934. :-)
>Lee
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett <[email protected]> writes:
>>No, it's a different raw driver, for big databases that basically want
>>their own custom filesystem on a disk.
>
> With the attendent possibility of rendering the whole thing
> unrecoverably moot?
>
> OTOH, if this database actually does have a better way, and its mature
> and proven, then I see no reason to cripple the database people just to
> remove what is viewed as a potentially dangerous path to the media
> surface for the unwashed to abuse.
The database people have a newer and supported way to do that, via the
O_DIRECT flag to open(). They aren't losing any functionality.
-Doug
On Saturday 21 January 2006 18:59, Doug McNaught wrote:
>Gene Heskett <[email protected]> writes:
>>>No, it's a different raw driver, for big databases that basically
>>> want their own custom filesystem on a disk.
>>
>> With the attendent possibility of rendering the whole thing
>> unrecoverably moot?
>>
>> OTOH, if this database actually does have a better way, and its
>> mature and proven, then I see no reason to cripple the database
>> people just to remove what is viewed as a potentially dangerous path
>> to the media surface for the unwashed to abuse.
>
>The database people have a newer and supported way to do that, via the
>O_DIRECT flag to open(). They aren't losing any functionality.
>
Good, but what about speed, is that impacted in any way they can
measure, or is this flag/method actually faster than the raw driver is?
>-Doug
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Sat, 2006-01-21 at 19:09 -0500, Gene Heskett wrote:
> On Saturday 21 January 2006 18:59, Doug McNaught wrote:
> >Gene Heskett <[email protected]> writes:
> >>>No, it's a different raw driver, for big databases that basically
> >>> want their own custom filesystem on a disk.
> >>
> >> With the attendent possibility of rendering the whole thing
> >> unrecoverably moot?
> >>
> >> OTOH, if this database actually does have a better way, and its
> >> mature and proven, then I see no reason to cripple the database
> >> people just to remove what is viewed as a potentially dangerous path
> >> to the media surface for the unwashed to abuse.
> >
> >The database people have a newer and supported way to do that, via the
> >O_DIRECT flag to open(). They aren't losing any functionality.
> >
> Good, but what about speed, is that impacted in any way they can
> measure, or is this flag/method actually faster than the raw driver is?
A loss of speed is a loss of functionality, and would not be accepted.
Lee
Lee Revell <[email protected]> writes:
> On Sat, 2006-01-21 at 19:09 -0500, Gene Heskett wrote:
>> Good, but what about speed, is that impacted in any way they can
>> measure, or is this flag/method actually faster than the raw driver is?
>
> A loss of speed is a loss of functionality, and would not be accepted.
Actually it's only partly about speed--they want to implement not only
their own filesystem but their own memory caching strategy, and don't
want the same data in their cache and the Linux page cache (which
would waste memory and possibly cause aliasing problems). Both the
raw driver and O_DIRECT allow direct writes to disk without going
through the page cache; there is no significant performance difference
(since performance is dominated by the time required to write a page
to disk). O_DIRECT is just a much cleaner way to do it, and is
also supported on other systems like Solaris IIRC.
-Doug
On Sat, 2006-01-21 at 19:09 -0500, Gene Heskett wrote:
> On Saturday 21 January 2006 18:59, Doug McNaught wrote:
> >Gene Heskett <[email protected]> writes:
> >>>No, it's a different raw driver, for big databases that basically
> >>> want their own custom filesystem on a disk.
> >>
> >> With the attendent possibility of rendering the whole thing
> >> unrecoverably moot?
> >>
> >> OTOH, if this database actually does have a better way, and its
> >> mature and proven, then I see no reason to cripple the database
> >> people just to remove what is viewed as a potentially dangerous path
> >> to the media surface for the unwashed to abuse.
> >
> >The database people have a newer and supported way to do that, via the
> >O_DIRECT flag to open(). They aren't losing any functionality.
> >
> Good, but what about speed, is that impacted in any way they can
> measure, or is this flag/method actually faster than the raw driver is?
the 2.6 raw driver is just a wrapper layer around this O_DIRECT open.
Adrian Bunk wrote:
> The oflag=direct option was added to GNU coreutils in version 5.3.0.
5.3.0 is "beta", 5.93 is "stable". But there is one thing that won't let
you use newer Coreutils: LSB, namely the Li18nux2000 tests. Coreutils is
one of those packages that never go to distros in their pristine form.
And, alas, there is still no working patch against Coreutils-5.93 that
allows passing the LSB testsuite completely. And distromakers won't
trade bugs tested in LSB for bugs unknown to LSB but fixed upstream. So,
users are really screwed.
--
Alexander E. Patrakov
On 1/21/06, Andrew Morton <[email protected]> wrote:
> Arjan van de Ven <[email protected]> wrote:
> >
> > another thing we really should do is making such "obsolete to be phased
> > out" things printk (at least once per boot ;) so that people see it in
> > their logs, not just in the kernel source.
>
> Like sys_bdflush() has been doing for 3-4 years. That still comes out on
> a few of my test boxes, but I'm a distro recidivist.
>
How about something like this?
- We extend the deadline by a year - that should give most people enough time.
- We make it *very clear* in text both in source comments, Kconfig,
feature-removal-schedule and elsewhere that this feature *will* die soon.
- We make the build spit lots of 'deprecated' warnings when people build it.
- We make use of RAW devices printk() a warning so even people who don't read
kernel documentation nor build their own kernels will notice.
Then next january we can kill the feature and rightfully claim that ample
warning has been given on all levels.
(patch also attached since gmail will likely break the inline version).
Signed-off-by: Jesper Juhl <[email protected]>
---
Documentation/feature-removal-schedule.txt | 6 +++---
Documentation/ioctl-mess.txt | 2 ++
drivers/char/Kconfig | 14 ++++++++++----
drivers/char/raw.c | 28 +++++++++++++++++-----------
fs/compat_ioctl.c | 8 ++++----
include/linux/compat_ioctl.h | 2 +-
include/linux/raw.h | 5 +++++
7 files changed, 42 insertions(+), 23 deletions(-)
--- linux-2.6.16-rc1-mm2-orig/Documentation/feature-removal-schedule.txt 2006-01-20
21:50:43.000000000 +0100
+++ linux-2.6.16-rc1-mm2/Documentation/feature-removal-schedule.txt 2006-01-22
18:19:17.000000000 +0100
@@ -18,9 +18,9 @@ Who: Greg Kroah-Hartman <[email protected]>
---------------------------
What: RAW driver (CONFIG_RAW_DRIVER)
-When: December 2005
-Why: declared obsolete since kernel 2.6.3
- O_DIRECT can be used instead
+When: January 2007
+Why: Declared obsolete since kernel 2.6.3
+ O_DIRECT can be used instead.
Who: Adrian Bunk <[email protected]>
---------------------------
--- linux-2.6.16-rc1-mm2-orig/drivers/char/Kconfig 2006-01-20
21:50:44.000000000 +0100
+++ linux-2.6.16-rc1-mm2/drivers/char/Kconfig 2006-01-22
18:39:23.000000000 +0100
@@ -945,10 +945,11 @@ config RAW_DRIVER
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.
+
+ Feature removal warning:
+ The raw driver is deprecated and will be removed in January 2007.
+ 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)"
@@ -958,6 +959,11 @@ config MAX_RAW_DEVS
The maximum number of RAW devices that are supported.
Default is 256. Increase this number in case you need lots of
raw devices.
+
+ Feature removal warning:
+ The raw driver is deprecated and will be removed in January 2007.
+ Applications should simply open the device (eg /dev/hda1)
+ with the O_DIRECT flag.
config HPET
bool "HPET - High Precision Event Timer" if (X86 || IA64)
--- linux-2.6.16-rc1-mm2-orig/include/linux/raw.h 2006-01-03
04:21:10.000000000 +0100
+++ linux-2.6.16-rc1-mm2/include/linux/raw.h 2006-01-22 18:20:30.000000000 +0100
@@ -1,3 +1,8 @@
+/*
+ * The RAW driver is obsolete and will go away in January 2007.
+ * Please use O_DIRECT instead.
+ */
+
#ifndef __LINUX_RAW_H
#define __LINUX_RAW_H
--- linux-2.6.16-rc1-mm2-orig/include/linux/compat_ioctl.h 2006-01-20
21:50:57.000000000 +0100
+++ linux-2.6.16-rc1-mm2/include/linux/compat_ioctl.h 2006-01-22
18:21:56.000000000 +0100
@@ -568,7 +568,7 @@ COMPATIBLE_IOCTL(DEVFSDIOC_GET_PROTO_REV
COMPATIBLE_IOCTL(DEVFSDIOC_SET_EVENT_MASK)
COMPATIBLE_IOCTL(DEVFSDIOC_RELEASE_EVENT_QUEUE)
COMPATIBLE_IOCTL(DEVFSDIOC_SET_DEBUG_MASK)
-/* Raw devices */
+/* Raw devices (obsolete and will go away January 2007 - don't use) */
COMPATIBLE_IOCTL(RAW_SETBIND)
COMPATIBLE_IOCTL(RAW_GETBIND)
/* SMB ioctls which do not need any translations */
--- linux-2.6.16-rc1-mm2-orig/fs/compat_ioctl.c 2006-01-20
21:50:48.000000000 +0100
+++ linux-2.6.16-rc1-mm2/fs/compat_ioctl.c 2006-01-22 18:23:37.000000000 +0100
@@ -2148,7 +2148,7 @@ struct raw32_config_request
__u64 block_minor;
} __attribute__((packed));
-static int get_raw32_request(struct raw_config_request *req, struct
raw32_config_request __user *user_req)
+static int __deprecated get_raw32_request(struct raw_config_request
*req, struct raw32_config_request __user *user_req)
{
int ret;
@@ -2162,7 +2162,7 @@ static int get_raw32_request(struct raw_
return ret ? -EFAULT : 0;
}
-static int set_raw32_request(struct raw_config_request *req, struct
raw32_config_request __user *user_req)
+static int __deprecated set_raw32_request(struct raw_config_request
*req, struct raw32_config_request __user *user_req)
{
int ret;
@@ -2176,7 +2176,7 @@ static int set_raw32_request(struct raw_
return ret ? -EFAULT : 0;
}
-static int raw_ioctl(unsigned fd, unsigned cmd, unsigned long arg)
+static int __deprecated raw_ioctl(unsigned fd, unsigned cmd, unsigned long arg)
{
int ret;
@@ -2913,7 +2913,7 @@ HANDLE_IOCTL(BLKGETSIZE64_32, do_blkgets
HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
HANDLE_IOCTL(REISERFS_IOC_UNPACK32, reiserfs_ioctl32)
-/* Raw devices */
+/* Raw devices (obsolete and will go away January 2007 - don't use) */
HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
/* Serial */
--- linux-2.6.16-rc1-mm2-orig/Documentation/ioctl-mess.txt 2006-01-20
21:50:43.000000000 +0100
+++ linux-2.6.16-rc1-mm2/Documentation/ioctl-mess.txt 2006-01-22
18:25:55.000000000 +0100
@@ -3385,6 +3385,8 @@ N: RAID_VERSION
I: -
O: struct mdu_version_s
+# Raw devices are obsolete and will go away in January 2007.
+# Please use O_DIRECT instead.
N: RAW_GETBIND
I: struct raw_config_request
O: struct raw_config_request
--- linux-2.6.16-rc1-mm2-orig/drivers/char/raw.c 2006-01-20
21:50:44.000000000 +0100
+++ linux-2.6.16-rc1-mm2/drivers/char/raw.c 2006-01-22 18:36:07.000000000 +0100
@@ -6,6 +6,9 @@
*
* 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.
+ *
+ * Raw devices are obsolete and going away in January 2007 in favour of
+ * O_DIRECT.
*/
#include <linux/init.h>
@@ -43,12 +46,15 @@ static struct file_operations raw_ctl_fo
* 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)
+static int __deprecated raw_open(struct inode *inode, struct file *filp)
{
const int minor = iminor(inode);
struct block_device *bdev;
int err;
+ printk(KERN_WARNING "RAW devices are obsolete and *WILL* be removed in"
+ " January 2007. Please use O_DIRECT instead.\n");
+
if (minor == 0) { /* It is the control device */
filp->f_op = &raw_ctl_fops;
return 0;
@@ -95,7 +101,7 @@ out:
* 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)
+static int __deprecated raw_release(struct inode *inode, struct file *filp)
{
const int minor= iminor(inode);
struct block_device *bdev;
@@ -117,8 +123,8 @@ static int raw_release(struct inode *ino
/*
* Forward ioctls to the underlying block device.
*/
-static int
-raw_ioctl(struct inode *inode, struct file *filp,
+static int
+__deprecated raw_ioctl(struct inode *inode, struct file *filp,
unsigned int command, unsigned long arg)
{
struct block_device *bdev = filp->private_data;
@@ -126,7 +132,7 @@ raw_ioctl(struct inode *inode, struct fi
return blkdev_ioctl(bdev->bd_inode, NULL, command, arg);
}
-static void bind_device(struct raw_config_request *rq)
+static void __deprecated bind_device(struct raw_config_request *rq)
{
class_device_destroy(raw_class, MKDEV(RAW_MAJOR, rq->raw_minor));
class_device_create(raw_class, NULL, MKDEV(RAW_MAJOR, rq->raw_minor),
@@ -137,7 +143,7 @@ static void bind_device(struct raw_confi
* 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,
+static int __deprecated raw_ctl_ioctl(struct inode *inode, struct file *filp,
unsigned int command, unsigned long arg)
{
struct raw_config_request rq;
@@ -239,8 +245,8 @@ out:
return err;
}
-static ssize_t raw_file_write(struct file *file, const char __user *buf,
- size_t count, loff_t *ppos)
+static ssize_t __deprecated raw_file_write(struct file *file,
+ const char __user *buf, size_t count, loff_t *ppos)
{
struct iovec local_iov = {
.iov_base = (char __user *)buf,
@@ -250,8 +256,8 @@ static ssize_t raw_file_write(struct fil
return generic_file_write_nolock(file, &local_iov, 1, ppos);
}
-static ssize_t raw_file_aio_write(struct kiocb *iocb, const char __user *buf,
- size_t count, loff_t pos)
+static ssize_t __deprecated raw_file_aio_write(struct kiocb *iocb,
+ const char __user *buf, size_t count, loff_t pos)
{
struct iovec local_iov = {
.iov_base = (char __user *)buf,
@@ -324,7 +330,7 @@ error:
return 1;
}
-static void __exit raw_exit(void)
+static void __deprecated __exit raw_exit(void)
{
int i;
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Sad, 2006-01-21 at 18:59 -0500, Doug McNaught wrote:
> > OTOH, if this database actually does have a better way, and its mature
> > and proven, then I see no reason to cripple the database people just to
> > remove what is viewed as a potentially dangerous path to the media
> > surface for the unwashed to abuse.
>
> The database people have a newer and supported way to do that, via the
> O_DIRECT flag to open(). They aren't losing any functionality.
And they'll no doubt update to use it on their cycles of development.
Which for some large vendor systems means five years.
Alan
>> > OTOH, if this database actually does have a better way, and its mature
>> > and proven, then I see no reason to cripple the database people just to
>> > remove what is viewed as a potentially dangerous path to the media
>> > surface for the unwashed to abuse.
>>
>> The database people have a newer and supported way to do that, via the
>> O_DIRECT flag to open(). They aren't losing any functionality.
>
>And they'll no doubt update to use it on their cycles of development.
>Which for some large vendor systems means five years.
>
"The main reason there are no raw devices [in Linux] is that I personally
think that raw devices are a stupid idea." (Linus Torvalds, 17 Oct 1996)
http://www.ussg.iu.edu/hypermail/linux/kernel/9610.2/0030.html (wikiquote)
That stands, but a raw driver found its way in someday.
(And now luckily is on its way out again.)
Jan Engelhardt
--