Hi Hans,
Thanks for your comments.
On Mon, Apr 30, 2012 at 03:48:14PM +0200, Hans Verkuil wrote:
> On Monday 30 April 2012 15:34:58 Sakari Ailus wrote:
> > Remove input field in struct v4l2_buffer and flag V4L2_BUF_FLAG_INPUT which
> > tells the former is valid. The flag is used by no driver currently.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxx>
> > ---
> > Hi all,
> >
> > I thought this would be a good time to get rid of the input field in
> > v4l2_buffer to avoid writing more useless compat code for it --- the enum
> > compat code.
> >
> > Comments are welcome. This patch is compile tested on videobuf and
> > videobuf2.
>
> I'm all in favor of this. Don't forget to update the documentation as well,
> though!
Good point. I'll go through that next.
> What would the impact be on applications, though? Any app that currently does
> 'reserved = 0' would fail to compile after this change.
I had a bit of that in drivers and videobuf(2), too.
Is there a known good practice of dealing with this? The reserved fields are
supposed to be set to zero by applications but the reserved fields may even
vanish over time from some structs.
One option is to keep the reserved fields as array even there was just one
of them or if it no longer was there. If so, reserved should have been
reserved[1] in the first place. This would make it easier to deal with
the changing size of the reserved field.
> Perhaps rather than removing 'input' and changing 'reserved' to 'reserved[2]'
> we should do something like this:
>
> union {
> u32 input;
> u32 reserved2;
> };
> u32 reserved;
>
> Or perhaps leave out the union and just replace 'input' by 'reserved2'.
That sounds like a good option to me, too.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
