Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: ioctl cleanups: enable sg_io and serial stuff to be shared | Date | Fri, 9 May 2003 00:48:05 +0200 |
| |
On Thursday 08 May 2003 22:33, Pavel Machek wrote:
> > BTW, need to extend this to netdev->do_ioctl as well for the > > handling of SIOCDEVPRIVATE based stuff. Oh goody, we can finally > > fix up that crap :)))) > > There's a *lot* of structs that contain *ioctl:
> atmdev.h: int (*ioctl)(struct atm_dev *dev,unsigned int cmd,void *arg); > atmdev.h: int (*ioctl)(struct atm_dev *dev,unsigned int cmd,void *arg); > fs.h: int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long); > fs.h: int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); > hdlc.h: int (*ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd); > ...
There are even some more that your grep did not catch. However, only few of them actually need to be changed if we add ->compat_ioctl().
For those subsystems that have a clearly defined set of ioctls that are implemented by the specific drivers, the compatibility code can be put in a higher level ioctl handler, e.g. atm_ioctl() instead of each of the atm drivers. Finding out exactly which interfaces need to be extended can be done in the process.
> What about this one: redefine it to (*ioctl)( ...., unsigned *long*, > unsinged long). That means we can add > > #define IOCTL_COMPAT 0x1 0000 0000
I had the same idea before but in addition to the problem that davem mentioned, this would require changing every single ioctl handler in the kernel and in third party drivers to use 'long' numbers. Not really something we want to do during the current freeze.
The three options that currently make sense to me are:
a) keep using register_ioctl32_conversion() for everything b) add a compat_task() function that handlers may use to decide if they should use the compat data structures, list those ioctls as COMPATIBLE_IOCTL() c) add ->compat_ioctl() to some interfaces, with HANDLE_IOCTL() as fallback
Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |