linux-kernel - Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 02 Dec 2014 14:59:29 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Hans Verkuil <hverkuil@...all.nl>
Cc:	Prabhakar Lad <prabhakar.csengg@...il.com>,
	linux-media <linux-media@...r.kernel.org>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()

Hi Hans,

On Tuesday 02 December 2014 13:53:05 Hans Verkuil wrote:
> On 12/02/14 08:45, Hans Verkuil wrote:
> > On 12/02/2014 12:26 AM, Laurent Pinchart wrote:
> >> On Sunday 30 November 2014 21:30:35 Prabhakar Lad wrote:
> >>> On Sun, Nov 30, 2014 at 9:16 PM, Laurent Pinchart wrote:
> >>>> On Sunday 30 November 2014 21:05:50 Prabhakar Lad wrote:
> >>>>> On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart wrote:
> >>>>>> Hi Prabhakar,
> >>>>> 
> >>>>> [Snip]
> >>>>> 
> >>>>>>>> Sure. That's a better choice than removing the config option
> >>>>>>>> dependency of the fields struct v4l2_subdev.
> >>>>>> 
> >>>>>> Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the
> >>>>>> in-kernel pad format and selection rectangles helpers is definitely a
> >>>>>> good idea. I was thinking about decoupling the try format and
> >>>>>> rectangles from v4l2_subdev_fh by creating a kind of configuration
> >>>>>> store structure to store them, and embedding that structure in
> >>>>>> v4l2_subdev_fh. The pad-level operations would then take a pointer to
> >>>>>> the configuration store instead of the v4l2_subdev_fh. Bridge drivers
> >>>>>> that want to implement TRY_FMT based on pad-level operations would
> >>>>>> create a configuration store, use the pad-level operations, and
> >>>>>> destroy the configuration store. The userspace subdev API would use
> >>>>>> the configuration store from the file handle.
> >>>>> 
> >>>>> are planning to work/post any time soon ? Or are you OK with
> >>>>> suggestion from Hans ?
> >>>> 
> >>>> I have no plan to work on that myself now, I was hoping you could
> >>>> implement it ;-)
> >>> 
> >>> OK will implement it.
> >>> 
> >>> Can you please elaborate a more on this "The userspace subdev API would
> >>> use the configuration store from the file handle."
> >> 
> >> Basically,
> >> 
> >> 1. Create a subdev pad configuration store structure to store the formats
> >> and selection rectangles for each pad.
> > 
> > I wouldn't call it a 'store'. Just call it fmt_config or pad_config
> > something like that.

Sure, the name doesn't matter too much.

> >> 2. Embed an instance of that structure in v4l2_subdev_fh.
> >> 
> >> 3. Modify the subdev pad ops to take a configuration store pointer
> >> instead of a file handle pointer.
> >> 
> >> The userspace API implementation (v4l2-subdev.c) would then pass
> >> &fh->store to the pad operations instead of fh.
> >> 
> >> Bridge drivers that need to implement TRY_FMT on top of pad ops would
> >> create a temporary store (or temporary stores when multiple subsdevs are
> >> involved), call the pad ops with a pointer to the temporary store to
> >> propagate TRY formats, destroy the store(s) and return the resulting
> >> format.
> > 
> > That will work. I think this is a good approach and it shouldn't be too
> > difficult.
>
> Laurent, just so I understand this correctly: does this mean that all
> occurrences of 'struct v4l2_subdev_fh *fh' will be replaced by 'struct
> v4l2_subdev_pad_config *cfg'?

That's the plan, yes.

> Is there any reason why the 'fh' should still be passed on?

We might find out reasons to still pass the fh, but in that case I think they 
should be addressed and the fh just dropped from the pad ops arguments.

> Personally I am in favor of this since the 'fh' always made it hard for
> bridge drivers to use these pad ops. So if we can replace it by something
> that can be used by bridge drivers as well, then that will make it easier
> to move all drivers over to the pad ops.

Good, looks like we have a plan for world domination :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/