linux-kernel - Re: [RFC PATCH 0/9] media: base request API support

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: <CAPBb6MUubHGnQ+rR+b8qtbhN4PPu3zBDBpckb1-nobCUAXv-4w@mail.gmail.com>
Date:   Wed, 20 Dec 2017 18:27:28 +0900
From:   Alexandre Courbot <acourbot@...omium.org>
To:     Nicolas Dufresne <nicolas@...fresne.ca>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Pawel Osciak <posciak@...omium.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Tomasz Figa <tfiga@...omium.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Gustavo Padovan <gustavo.padovan@...labora.com>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/9] media: base request API support

On Sat, Dec 16, 2017 at 6:04 AM, Nicolas Dufresne <nicolas@...fresne.ca> wrote:
> Le vendredi 15 décembre 2017 à 16:56 +0900, Alexandre Courbot a écrit :
>> Here is a new attempt at the request API, following the UAPI we agreed on in
>> Prague. Hopefully this can be used as the basis to move forward.
>>
>> This series only introduces the very basics of how requests work: allocate a
>> request, queue buffers to it, queue the request itself, wait for it to complete,
>> reuse it. It does *not* yet use Hans' work with controls setting. I have
>> preferred to submit it this way for now as it allows us to concentrate on the
>> basic request/buffer flow, which was harder to get properly than I initially
>> thought. I still have a gut feeling that it can be improved, with less back-and-
>> forth into drivers.
>>
>> Plugging in controls support should not be too hard a task (basically just apply
>> the saved controls when the request starts), and I am looking at it now.
>>
>> The resulting vim2m driver can be successfully used with requests, and my tests
>> so far have been successful.
>>
>> There are still some rougher edges:
>>
>> * locking is currently quite coarse-grained
>> * too many #ifdef CONFIG_MEDIA_CONTROLLER in the code, as the request API
>>   depends on it - I plan to craft the headers so that it becomes unnecessary.
>>   As it is, some of the code will probably not even compile if
>>   CONFIG_MEDIA_CONTROLLER is not set
>
> Would it be possible to explain why this relation between request and
> the media controller ? Why couldn't request be created from video
> devices ?

Laurent replied on IRC, but for the record this is because the media
node can act as an orchestrator to the devices it manages. Some
devices may have particular needs in that respect, and we want to be
able to hook somewhere and control that.

Another reason is that in the future the media framework will probably
take more importance, to the point where you could control the whole
chain of devices through it instead of having to open every node
individually. This is a different topic though, and we only touched
the surface of it during the latest mini-summit.