linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC API] Renumber subdev ioctls
Date: Mon, 20 Aug 2012 16:05:03 -0300	[thread overview]
Message-ID: <50328A5F.20303@redhat.com> (raw)
In-Reply-To: <201208201030.30590.hverkuil@xs4all.nl>

Em 20-08-2012 05:30, Hans Verkuil escreveu:
> Hi all!
> 
> Recently I had to add two new ioctls for the subdev API (include/linux/v4l2-subdev.h)
> and I noticed that the numbering of the ioctls was somewhat random.
> 
> In most cases the ioctl number was the same as the V4L2 API counterpart, but for
> subdev-specific ioctls no rule exists.
> 
> There are a few problems with this: because of the lack of rules there is a chance
> that in the future a subdev ioctl may end up to be identical to an existing V4L2
> ioctl. Also, because the numbering isn't nicely increasing it makes it hard to create
> a lookup table as was done for the V4L2 ioctls. Well, you could do it, but it would
> be a very sparse array, wasting a lot of memory.
> 
> Lookup tables have proven to be very useful, so we might want to introduce them for
> the subdev core code as well in the future.
> 
> Since the subdev API is still marked experimental, I propose to renumber the ioctls
> and use the letter 'v' instead of 'V'. 'v' was used for V4L1, and so it is now
> available for reuse.

'v' is already used (mainly by fs):

'v'	00-1F	linux/ext2_fs.h		conflict!
'v'	00-1F	linux/fs.h		conflict!
'v'	00-0F	linux/sonypi.h		conflict!
'v'	C0-FF	linux/meye.h		conflict!

Reusing the ioctl numbering is a bad thing, as tracing code like strace will likely
say that a different type of ioctl was called.

(Yeah, unfortunately, this end by merging with duplicated stuff :< )

Also, I don't like the idea of deprecating it just because of that: interfaces are
supposed to be stable.

It should be noticed that there are very few ioctls there. So,
using a lookup table is overkill.

IMO, the better is to sort the ioctl's there at the header file, in order to
avoid ioctl duplicaton.


> We keep the old ioctls around for a few kernel cycles, and remove them some time
> next year.
> 
> Note that some V4L2 ioctls are also available for use in the subdev API (control
> ioctls in particular). By using a different letter for the ioctls this will make
> it easy as well to decide what lookup table to use should we decide to introduce
> that in the subdev core code in the future.
> 
> Comments?
> 
> Regards,
> 
> 	Hans
> 


  reply	other threads:[~2012-08-20 19:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-20  8:30 [RFC API] Renumber subdev ioctls Hans Verkuil
2012-08-20 19:05 ` Mauro Carvalho Chehab [this message]
2012-08-20 20:46   ` Sakari Ailus
2012-08-21  6:39     ` Hans Verkuil
2012-08-21  9:01       ` Laurent Pinchart
2012-08-21 11:06         ` Sakari Ailus
2012-08-21 10:44       ` Sakari Ailus
2012-08-22  8:52         ` Hans Verkuil
2012-08-22 18:18           ` Mauro Carvalho Chehab
2012-08-25  8:55           ` Sakari Ailus

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=50328A5F.20303@redhat.com \
    --to=mchehab@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).