All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist
Date: Sun, 26 Jun 2011 15:51:37 -0300	[thread overview]
Message-ID: <4E077FB9.7030600@redhat.com> (raw)
In-Reply-To: <201106262020.20432.arnd@arndb.de>

Em 26-06-2011 15:20, Arnd Bergmann escreveu:
> 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.

Yes.  This discussion was originated by a RFC patch proposing to change 
video_ioctl2 to return -ENOIOCTLCMD instead of -EINVAL.

>> 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?

Yes. The patch in question is also changing the DocBook spec for the ABI. We'll
likely need to drop some notes about that at the features-to-be-removed.txt.

I don't think that applications are relying at -EINVAL in order to detect if
an ioctl is not supported, but before merging such patch, we need to double-check.

Mauro.

  reply	other threads:[~2011-06-26 18:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24 23:11 [PATCH] [media] v4l2 core: return -ENOIOCTLCMD if an ioctl doesn't exist Mauro Carvalho Chehab
2011-06-26 15:40 ` Sakari Ailus
2011-06-26 16:20   ` Mauro Carvalho Chehab
2011-06-26 17:13     ` Arnd Bergmann
2011-06-26 17:30       ` Mauro Carvalho Chehab
2011-06-26 18:20         ` Arnd Bergmann
2011-06-26 18:51           ` Mauro Carvalho Chehab [this message]
2011-06-26 19:52             ` Arnd Bergmann
2011-06-27  5:38             ` Hans Verkuil
2011-06-27 12:02               ` Sakari Ailus
2011-06-27 12:17                 ` Hans Verkuil
2011-06-27 12:17                   ` Hans Verkuil
2011-06-27 13:54                   ` Mauro Carvalho Chehab
2011-06-27 14:56                     ` Hans Verkuil
2011-06-27 15:33                       ` Mauro Carvalho Chehab
2011-06-27 16:14                         ` Arnd Bergmann
2011-06-27 16:42                           ` Mauro Carvalho Chehab
2011-06-27 17:07                         ` Hans Verkuil
2011-06-27 20:37                           ` Mauro Carvalho Chehab
2011-06-27 20:48                           ` Linus Torvalds
2011-06-28  6:04                             ` Hans Verkuil
2011-06-28 16:05                               ` Linus Torvalds
2011-06-28 16:42                                 ` Alan Cox
2011-06-28 16:50                                   ` Arnd Bergmann
2011-06-29 12:34                                 ` Mauro Carvalho Chehab
2011-06-27 15:12                     ` Andy Walls
2011-06-27 15:12                       ` Andy Walls
2011-06-27 15:24                       ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E077FB9.7030600@redhat.com \
    --to=mchehab@redhat.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@iki.fi \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.