All of lore.kernel.org
 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 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.