linux-kernel - Re: [PATCH] media: cedrus: Update TODO with future rework plans

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] [day] [month] [year] [list]

Message-ID: <2cca0360b0a2a7d4032b02a16ae8f5c2a83283ef.camel@collabora.com>
Date:   Tue, 07 Nov 2023 15:35:26 -0500
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Maxime Ripard <mripard@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Jonas Karlman <jonas@...boo.se>,
        Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [PATCH] media: cedrus: Update TODO with future rework plans

Le mardi 07 novembre 2023 à 21:06 +0100, Paul Kocialkowski a écrit :
> The current TODO list of the cedrus driver is now outdated as most of the points
> it mentions were already tackled. In addition it is no longer considered
> relevant to wait for a stateless encoder driver to move it out of staging.
> The hantro/verisilicon driver was already unstaged without this condition.
> 
> However the driver suffers from a bad initial design that showed to be very
> limiting. It was also not a very good fit for a video codec driver either.
> 
> Since a rework of the driver was already carried out for the purpose of adding
> encoding support, update the TODO list with a description of the rework.
> This reworked driver will be published soon and transitional commits from the
> current driver will be submitted upstreamer after that.
> 
> It seems best to wait for the rework to land upstream before unstaging the
> driver, since a major rework is best operated on a staging driver instead of a
> fully upstream one.
> 
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>

Acked-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>

> ---
>  drivers/staging/media/sunxi/cedrus/TODO | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/TODO b/drivers/staging/media/sunxi/cedrus/TODO
> index ec277ece47af..00aa304a7e36 100644
> --- a/drivers/staging/media/sunxi/cedrus/TODO
> +++ b/drivers/staging/media/sunxi/cedrus/TODO
> @@ -1,7 +1,16 @@
> -Before this stateless decoder driver can leave the staging area:
> -* The Request API needs to be stabilized;
> -* The codec-specific controls need to be thoroughly reviewed to ensure they
> -  cover all intended uses cases;
> -* Userspace support for the Request API needs to be reviewed;
> -* Another stateless decoder driver should be submitted;
> -* At least one stateless encoder driver should be submitted.
> +This driver suffers from a bad initial design that results in various aspects
> +being intricated, making it difficult to scale to new codecs and to add encoding
> +support in the future.
> +
> +Before leaving the staging area, it should be reworked to clearly distinguish
> +between different aspects:
> +- platform, with resources management, interrupt handler, watchdog,
> +  v4l2 and m2m devices registration;
> +- proc, with video device registration and related operations;
> +- context, with m2m context, queue and controls management;
> +- engine, with each individual codec job execution and codec-specific
> +  operation callbacks;
> +
> +This will make it possible to register two different procs (decoder and
> +encoder) while sharing significant common infrastructure, common v4l2 and m2m
> +devices but exposing distinct video devices.