On Wed, Jan 26, 2011 at 07:20:07AM +1000, Linus Torvalds wrote:

On Wed, Jan 26, 2011 at 7:01 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

BTW, another issue is that evdev's ioctl returns -EINVAL for unknown
ioctls so applications would have hard time figuring out whether error
returned because of kernel being too old or because they are trying to
retrieve/establish invalid mapping if they had to go only by the error
code.

So that's just another evdev interface bug.

Huh? I do not have lot of options here as far as error codes go. Invalid
request, invalid data in request - all goes to EINVAL.

quoted

As far as I can see EINVAL is a proper error for unknown ioctls:

[dtor@hammer work]$ man 2 ioctl | grep EINVAL
      EINVAL Request or argp is not valid.

Yeah, there's some confusion there.

The "unknown ioctl" error code is (for traditional reasons) ENOTTY,
but yes, the EINVAL thing admittedly has a lot of legacy use too.

Inside the kernel, the preferred way to say "I don't recognize that
ioctl number" is actually ENOIOCTLCMD.  That's exactly so that various
nested ioctl handlers can then tell the difference between "I didn't
recognize that ioctl" and "I understand what you asked me to do, but
your arguments were crap".

vfs_ioctl() will then turn ENOIOCTLCMD to EINVAL to return to user space.

OK, so I can change evdev to employ ENOIOCTLCMD where needed, bit that
will not change older kernels where such distinction is needed (as never
kernels do support newer ioctl). And even if I could go back it would
not help since userspace still sees EINVAL only.

-- 
Dmitry