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: <68ba7b3f-57f5-3969-5036-2c8d08273548@xs4all.nl>
Date:   Fri, 24 Mar 2023 16:18:09 +0100
From:   Hans Verkuil <hverkuil-cisco@...all.nl>
To:     Nicolas Dufresne <nicolas@...fresne.ca>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     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

On 24/03/2023 16:14, Nicolas Dufresne wrote:
> 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 ?

I wouldn't mind if we can make a much nicer CREATE_BUFS variant with just the
size instead of a format. That was in hindsight a really bad idea, terrible
over-engineering.

Regards,

	Hans