linux-kernel - Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list

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]

Message-ID: <2d6480e36ce061a63440d1e11d52b02e57ba746d.camel@ndufresne.ca>
Date:   Fri, 24 Mar 2023 11:14:52 -0400
From:   Nicolas Dufresne <nicolas@...fresne.ca>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     Hans Verkuil <hverkuil-cisco@...all.nl>,
        David Laight <David.Laight@...LAB.COM>,
        Benjamin Gaignard <benjamin.gaignard@...labora.com>,
        "tfiga@...omium.org" <tfiga@...omium.org>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "ming.qian@....com" <ming.qian@....com>,
        "shijie.qin@....com" <shijie.qin@....com>,
        "eagle.zhou@....com" <eagle.zhou@....com>,
        "bin.liu@...iatek.com" <bin.liu@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "tiffany.lin@...iatek.com" <tiffany.lin@...iatek.com>,
        "andrew-ct.chen@...iatek.com" <andrew-ct.chen@...iatek.com>,
        "yunfei.dong@...iatek.com" <yunfei.dong@...iatek.com>,
        "stanimir.k.varbanov@...il.com" <stanimir.k.varbanov@...il.com>,
        "quic_vgarodia@...cinc.com" <quic_vgarodia@...cinc.com>,
        "agross@...nel.org" <agross@...nel.org>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "konrad.dybcio@...aro.org" <konrad.dybcio@...aro.org>,
        "ezequiel@...guardiasur.com.ar" <ezequiel@...guardiasur.com.ar>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "daniel.almeida@...labora.com" <daniel.almeida@...labora.com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-rockchip@...ts.infradead.org" 
        <linux-rockchip@...ts.infradead.org>,
        "kernel@...labora.com" <kernel@...labora.com>
Subject: Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list

Le mercredi 22 mars 2023 à 17:01 +0200, Laurent Pinchart a écrit :
> On Wed, Mar 22, 2023 at 10:50:52AM -0400, Nicolas Dufresne wrote:
> > Hi Laurent,
> > 
> > Le lundi 20 mars 2023 à 01:33 +0200, Laurent Pinchart a écrit :
> > > > The typical usage is that applications allocate N buffers with the
> > > > VIDIOC_REQBUFS ioctl, and in most cases that's all they use.
> > > 
> > > Note that once we get DELETE_BUF (or DELETE_BUFS) support I'd like to
> > > encourage applications to use the new API, and deprecate REQBUFS
> > > (dropping it isn't on my radar, as it would take forever before no
> > > userspace uses it anymore).
> > 
> > I was wondering if you can extend on this. I'm worried the count semantic might
> > prevent emulating it over create_bufs() ops, but if that works, did you meant to
> > emulate it so driver no longer have to implement reqbufs() if they have
> > create_bufs() ?
> 
> For drivers it should be fairly simply, as the reqbufs and create_bufs
> ioctl handlers should just point to the corresponding videobuf2 helpers.
> 
> What I meant is that I'd like to encourage userspace to use the
> VIDIOC_CREATE_BUFS ioctl instead of VIDIOC_REQBUFS.
> 

I'm not sure what rationale I can give implementer to "encourage" them to use a
more complex API that needs to copy over the FMT (which has just been set),
specially in the initial pre-allocation case. For most, CREATE_BUFS after SMT
will look like a very redundant and counter intuitive thing. Maybe you have a
more optimistic view on the matter ? Or you have a better idea how we could give
a meaning to having a fmt there on the initial case where the allocation matches
the queue FMT ?

Nicolas