public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	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: Mon, 27 Jun 2011 13:42:19 -0300	[thread overview]
Message-ID: <4E08B2EB.7020306@redhat.com> (raw)
In-Reply-To: <201106271814.36251.arnd@arndb.de>

Em 27-06-2011 13:14, Arnd Bergmann escreveu:
> On Monday 27 June 2011, Mauro Carvalho Chehab wrote:
>>> The point is that the spec can easily be improved to make such 'NOP' operations
>>> explicit, or to require that if a capability is present, then the corresponding
>>> ioctl(s) must also be present. Things like that are easy to verify as well with
>>> v4l2-compliance.
>>
>> We currently have more than 64 ioctl's. Adding a capability bit for each doesn't
>> seem the right thing to do. Ok, some could be grouped, but, even so, there are
>> drivers that implement the VIDIOC_G, but doesn't implement the corresponding VIDIO_S.
>> So, I think we don't have enough available bits for doing that.
> 
> It shouldn't be too hard to do an ioctl command that returns a le_bitmask with the
> ioctl command number as an index (0 to 91, currently), and the bit set for each
> command that has the corresponding v4l2_ioctl_ops member filled for the device.
> That would be an obvious way to query the operations, but I don't know if it's
> useful.

Tricks like that could be done, but that would not be consistent with other subsystems
that use -ENOTTY for such purpose. 

Also, to avoid having magic numbers, this will end by adding a somewhat complex logic 
at userspace (or having some sort of macro exported together with videodev2.h), in 
order to associate a V4L2 ioctl with the corresponding le_bitmask bit.

Also, 91 ioctls seems a complex-enough API to me. We should avoid adding more stuff there
without very good reasons.

In any case, we should also double check how this is done by the other API's used at the
media subsystem, and try to do the same there (lirc, Media Controller and DVB APIs).

My intention is to split the error handling changes from the original series that remove
the linux/version.h, and spend some time preparing a new RFC about that, trying to cover
all the API's defined under drivers/media. One idea could be to postpone a decision about
it, and discuss this topic further during the media workshop at the KS/2011.

Thanks,
Mauro.

  reply	other threads:[~2011-06-27 16:42 UTC|newest]

Thread overview: 26+ 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
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 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 [this message]
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: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=4E08B2EB.7020306@redhat.com \
    --to=mchehab@redhat.com \
    --cc=arnd@arndb.de \
    --cc=hverkuil@xs4all.nl \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox