Re: [RFC] Remove or convert empty ioctls ?

[Thomas Gleixner]

On Thu, 15 Oct 2009, Alan Cox wrote:
> Anyway the case discussed which is ".unlocked_ioctl = NULL" should return
> -ENOTTY, and there isn't any argument about the driver authors intentions.

I think we got some confusion finally. :)

If both unlocked_ioctl and ioctl are NULL the return code is -ENOTTY.

We have locked ioctl functions which return -ENOIOCTLCMD. vfs_ioctl()
returns that to user space, but for unlocked_ioctl it is translated to
-EINVAL. I guess we need to fix that either in the ioctl
implementations or let vfs_ioctl() translate it for locked ioctls as
well.

The other category of ioctls (both locked and unlocked) are the stub
functions which simply return -EINVAL or -ENOIOCTLCMD.

The spec says:
    EINVAL: The request or arg argument is not valid for this device.

    ENOTTY: The fildes argument is not associated with a STREAMS
    	    device that accepts control functions.

So for the stub ioctl functions EINVAL is a correct return value
because the driver has an ioctl function, but does not handle the
request.

But I completely agree, that we should remove those stubs simply
because they handle no request at all which is basically the same as
no ioctl function.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/