Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1269511rwl; Fri, 24 Mar 2023 08:20:25 -0700 (PDT) X-Google-Smtp-Source: AKy350Yat/0SbOAxNuqkvDZXGDdMg+1alOUBAHzMFXo7bGgewVsBBeNH3hNbVZdlBb8etl7j/n5t X-Received: by 2002:a05:6402:184f:b0:4fc:494a:98f5 with SMTP id v15-20020a056402184f00b004fc494a98f5mr3799379edy.29.1679671225149; Fri, 24 Mar 2023 08:20:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679671225; cv=none; d=google.com; s=arc-20160816; b=s+nDVB2XgTGh4gLUiCKzxsiU7hDRKWEtZFeqxpyy4/bUegkB81lv3N6MWU+nyIfmSW gJz9qWOJG0+uo/HNjK4p5pMT9XAQMp61plcV1BReEmBZBf3BTAMh9CQ/EQB2lehU2uxk tx/BP1n6xu0zJZoqkPtoueykn3QFOkMPjRvi4wgbwwwE+S4fOo/lFAX4dKmGQxwNOXz3 V7MdI8afgab0xE6Z2Q274hoqzRSyhYOOeg3Q2yifEqO9xPMoQJK/8qe2GeOWK3lFr3wE KXgZPi2kdR64bIRGEGZd47Isb4B11m2pDbHj//t2wsIU66RhoRen68WDi3sLtZzvBInV qT8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=p4XComTE4i6SDGb8Nd12lKuqwC4Bpv8edDFxbst2By0=; b=k1WiKuNKAgdrIX6mgAcFiUlH+jpjpMSXFaQhY8EwYYpYovD5jPPHntqBgTjs/XNya7 WMe2uYszacQN9Zm1G3Zd3WYGAa6zjvuOBIMZK/6JuQTzFiqy1HkzUrLw0GRlm+BBwmzI FlUP27diZz1mWO+yDACedah+Ri5yF6S7u+fvADc9WZ/Uj9irrVOEr/33283NHvqfVRR0 pOcThqM8Ff4hJXOHTkhtfLMrni+cEgUtNWHiRL6kbXbmkhKClUikT8TxkKPJGdPh8hch hWWzgx0rQnlLVhYsKlN9stpYUnBduUzGbMsJe1vkqLMl1dn0wnO3vwsxdGx/v3SSMVpH 76zg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v7-20020aa7d807000000b00501d4810b84si11898588edq.376.2023.03.24.08.20.00; Fri, 24 Mar 2023 08:20:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231869AbjCXPSV (ORCPT + 99 others); Fri, 24 Mar 2023 11:18:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231878AbjCXPSS (ORCPT ); Fri, 24 Mar 2023 11:18:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0199CA0B; Fri, 24 Mar 2023 08:18:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 75B9C62B74; Fri, 24 Mar 2023 15:18:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6113C433D2; Fri, 24 Mar 2023 15:18:10 +0000 (UTC) Message-ID: <68ba7b3f-57f5-3969-5036-2c8d08273548@xs4all.nl> Date: Fri, 24 Mar 2023 16:18:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list Content-Language: en-US To: Nicolas Dufresne , Laurent Pinchart Cc: David Laight , Benjamin Gaignard , "tfiga@chromium.org" , "m.szyprowski@samsung.com" , "mchehab@kernel.org" , "ming.qian@nxp.com" , "shijie.qin@nxp.com" , "eagle.zhou@nxp.com" , "bin.liu@mediatek.com" , "matthias.bgg@gmail.com" , "angelogioacchino.delregno@collabora.com" , "tiffany.lin@mediatek.com" , "andrew-ct.chen@mediatek.com" , "yunfei.dong@mediatek.com" , "stanimir.k.varbanov@gmail.com" , "quic_vgarodia@quicinc.com" , "agross@kernel.org" , "andersson@kernel.org" , "konrad.dybcio@linaro.org" , "ezequiel@vanguardiasur.com.ar" , "p.zabel@pengutronix.de" , "daniel.almeida@collabora.com" , "linux-media@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mediatek@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "linux-rockchip@lists.infradead.org" , "kernel@collabora.com" References: <20230313135916.862852-1-benjamin.gaignard@collabora.com> <20230313135916.862852-3-benjamin.gaignard@collabora.com> <20230313181155.GC22646@pendragon.ideasonboard.com> <86df05244d974416903e919d387a0a0b@AcuMS.aculab.com> <20230319233358.GD20234@pendragon.ideasonboard.com> <20230322150153.GO20234@pendragon.ideasonboard.com> <2d6480e36ce061a63440d1e11d52b02e57ba746d.camel@ndufresne.ca> From: Hans Verkuil In-Reply-To: <2d6480e36ce061a63440d1e11d52b02e57ba746d.camel@ndufresne.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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