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
>
next prev parent 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).