On Sunday 26 June 2011 19:30:46 Mauro Carvalho Chehab wrote: > > There was a lot of debate whether undefined ioctls on non-ttys should > > return -EINVAL or -ENOTTY, including mass-conversions from -ENOTTY to > > -EINVAL at some point in the pre-git era, IIRC. > > > > Inside of v4l2, I believe this is handled by video_usercopy(), which > > turns the driver's -ENOIOCTLCMD into -ENOTTY. What cases do you observe > > where this is not done correctly and we do return ENOIOCTLCMD to > > vfs_ioctl? > > Well, currently, it is returning -EINVAL maybe due to the mass-conversions > you've mentioned. I mean what do you return *to* vfs_ioctl from v4l? The conversions must have been long before we introduced compat_ioctl and ENOIOCTLCMD. As far as I can tell, video_ioctl2 has always converted ENOIOCTLCMD into EINVAL, so changing the vfs functions would not have any effect. > The point is that -EINVAL has too many meanings at V4L. It currently can be > either that an ioctl is not supported, or that one of the parameters had > an invalid parameter. If the userspace can't distinguish between an unimplemented > ioctl and an invalid parameter, it can't decide if it needs to fall back to > some different methods of handling a V4L device. > > Maybe the answer would be to return -ENOTTY when an ioctl is not implemented. That is what a lot of subsystems do these days. But wouldn't that change your ABI? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
