Re: [discuss] Re: unregister_ioctl32_conversion and modules. ioct l32 revisited.

From: Arnd Bergmann
Date: Wed Jan 05 2005 - 11:28:45 EST


On Middeweken 05 Januar 2005 16:25, Michael S. Tsirkin wrote:
> You mean like this?

Yes, except that

> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxxxxxx>
> --- linux-2.6.10/fs/ioctl.c.ok  2005-01-05 21:13:46.165718632 +0200
> +++ linux-2.6.10/fs/ioctl.c     2005-01-05 21:14:09.341195424 +0200
> @@ -162,7 +162,7 @@ asmlinkage long sys_ioctl(unsigned int f
>  out:
>         fput_light(filp, fput_needed);
>  out2:
> -       return error;
> +       return error==-ENOIOCTLCMD?-ENOTTY:error;
>  }
>
>  /*

- Spacing is broken.
- I think the convention would be to use EINVAL here. ENOTTY mean 'this
device does not support ioctl', while EINVAL is used for 'ioctl is
supported, but not this number'.
- I would put the conversion only in the place that calls ->native_ioctl
in order to make clearer why it is done.

> --- linux-2.6.10/fs/compat.c.ok 2005-01-05 21:15:34.221291688 +0200
> +++ linux-2.6.10/fs/compat.c    2005-01-05 21:16:04.922624376 +0200
> @@ -476,7 +476,7 @@ asmlinkage long compat_sys_ioctl(unsigne
>  out:
>         fput_light(filp, fput_needed);
>  out2:
> -       return error;
> +       return error==-ENOIOCTLCMD?-ENOTTY:error;
>  }
>
>  static int get_compat_flock(struct flock *kfl, struct compat_flock __user *ufl)

I don't think it's needed for the compat case, as we are already
handling ENOIOCTLCMD here by doing to hash lookup.

I'd also prefer the code to be based on Christophs version, which
unfortunately is lacking handling for ENOIOCTLCMD from compat_ioctl,
but otherwise looks better.

Arnd <><

Attachment: pgp00000.pgp
Description: signature