linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Manik Raina <manik@cisco.com>, linux-kernel@vger.kernel.org
Subject: Re: ioctl conflicts
Date: Thu, 30 Aug 2001 03:15:02 -0600	[thread overview]
Message-ID: <20010830031502.G541@turbolinux.com> (raw)
In-Reply-To: <3B8DEF9D.26F7544D@cisco.com> <E15cN49-0000fz-00@the-village.bc.nu>
In-Reply-To: <E15cN49-0000fz-00@the-village.bc.nu>

On Aug 30, 2001  09:20 +0100, Alan Cox wrote:
> Manik Raina wrote:
> > I was grep-ing on a 2.4 source tree when i found the
> > following :
> > 
> > ./include/linux/videodev.h:#define VIDIOCGCAP          
> > _IOR('v',1,struct video_capability)
> > ./include/linux/ext2_fs.h:#define  EXT2_IOC_GETVERSION  _IOR('v',1,
> > long)   

Note that these ioctls _should_ still have different numbers because
of the struct sizes, but it is still a small conflict.

> Thats fine. ext2 ioctls and video ioctls go to different places

I had proposed a patch to the ext2 folks to remove the use of the 'v'
space ioctls from ext2.  This would (naturally) be a slow process,
first adding new ioctl numbers in the 'f' space with equivalent function,
then when we expect a reasonable percentage of systems with the new
ioctls, change the tools to try the new ones first and fall back to the
old ones, and finally removing the old ioctls completely.

While there were no complaints, it was a rather luke-warm reception.
There is one good reason to fix the conflict - strace doesn't have
to worry about IOC number conflicts, and can print the symbolic name.

Since these particular ioctls (EXT2_IOC_{GET,SET}VERSION) are not
particularly widely used, it shouldn't be a huge effort to change.
The first part of the change is below (it is already part of ext3 for
2.4).  It should pretty much apply cleanly to 2.2 as well as I don't
think this area has changed very much at all, and it can not possibly
do any harm.

Maybe for 2.5/2.6 a warning message would be printed if the old ioctl
number is being used, and 3.x would remove the old ioctl (4+ years
from now or so).

Cheers, Andreas
=======================================================================
diff -ru linux-2.4.7.orig/fs/ext2/ioctl.c linux-2.4.7-aed/fs/ext2/ioctl.c
--- linux-2.4.7.orig/fs/ext2/ioctl.c	Wed Sep 27 14:41:33 2000
+++ linux-2.4.7-aed/fs/ext2/ioctl.c	Tue Jul 31 16:27:55 2001
@@ -73,9 +73,11 @@
 		mark_inode_dirty(inode);
 		return 0;
 	}
-	case EXT2_IOC_GETVERSION:
+	case EXT2_IOC_GETVERSION_OLD:
+	case EXT2_IOC_GETVERSION_NEW:
 		return put_user(inode->i_generation, (int *) arg);
-	case EXT2_IOC_SETVERSION:
+	case EXT2_IOC_SETVERSION_OLD:
+	case EXT2_IOC_SETVERSION_NEW:
 		if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
 			return -EPERM;
 		if (IS_RDONLY(inode))
diff -ru linux-2.4.7.orig/include/linux/ext2_fs.h linux-2.4.7-aed/include/linux/ext2_fs.h
--- linux-2.4.7.orig/include/linux/ext2_fs.h	Tue Jul 31 15:00:43 2001
+++ linux-2.4.7-aed/include/linux/ext2_fs.h	Tue Jul 31 16:27:45 2001
@@ -208,8 +212,15 @@
  */
 #define	EXT2_IOC_GETFLAGS		_IOR('f', 1, long)
 #define	EXT2_IOC_SETFLAGS		_IOW('f', 2, long)
-#define	EXT2_IOC_GETVERSION		_IOR('v', 1, long)
-#define	EXT2_IOC_SETVERSION		_IOW('v', 2, long)
+#define	EXT2_IOC_GETVERSION_NEW		_IOR('f', 3, long)
+#define	EXT2_IOC_SETVERSION_NEW		_IOW('f', 4, long)
+#define	EXT2_IOC_GETVERSION_OLD		_IOR('v', 1, long)
+#define	EXT2_IOC_SETVERSION_OLD		_IOW('v', 2, long)
+/* Use the old ioctl numbers for now, until we have had the new ioctl
+ * numbers around for a good while (in case user-space includes this file).
+ */
+#define EXT2_IOC_GETVERSION EXT2_IOC_GETVERSION_OLD
+#define EXT2_IOC_SETVERSION EXT2_IOC_SETVERSION_OLD
 
 /*
  * Structure of an inode on the disk
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert


  reply	other threads:[~2001-08-30  9:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-28 12:53 Size of pointers in sys_call_table? Harald Barth
2001-08-28 13:26 ` Brian Gerst
2001-08-28 14:30   ` Harald Barth
2001-08-28 16:17   ` Alan Cox
2001-08-29  0:49     ` Keith Owens
2001-08-29 23:26     ` Ralf Baechle
2001-08-30  7:47 ` ioctl conflicts Manik Raina
2001-08-30  8:16   ` Gerd Knorr
2001-08-30  9:34     ` Manik Raina
2001-08-30  8:20   ` Alan Cox
2001-08-30  9:15     ` Andreas Dilger [this message]
2001-09-03  1:06     ` Wichert Akkerman
2001-08-30  8:30   ` David S. Miller
2001-08-30  9:00     ` Andreas Schwab
2001-08-30  9:14     ` Alan Cox
2001-08-30  9:29     ` David S. Miller
2001-08-30  9:31   ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010830031502.G541@turbolinux.com \
    --to=adilger@turbolabs.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manik@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).