[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe2dc70b-915c-ca2b-be81-a8ee66cf41cd@asahilina.net>
Date: Tue, 2 May 2023 05:17:08 +0900
From: Asahi Lina <lina@...hilina.net>
To: Nicolas Dufresne <nicolas.dufresne@...labora.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Daniel Almeida <daniel.almeida@...labora.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Hans Verkuil <hverkuil@...all.nl>, wedsonaf@...il.com,
ojeda@...nel.org, mchehab@...nel.org,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, kernel@...labora.com,
Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
On 02/05/2023 05.10, Nicolas Dufresne wrote:
> Le mercredi 26 avril 2023 à 20:25 +0300, Laurent Pinchart a écrit :
>> Hi Daniel,
>>
>> On Wed, Apr 26, 2023 at 06:14:33PM +0100, Daniel Almeida wrote:
>>> Hi,
>>>
>>> As I said higher up on this thread, I can maintain the Rust bits and
>>> help out with the issues around it.
>>>
>>> IMHO, we should at least try this. Who knows, it might work out :)
>>>
>>> Laurent, maybe we can take a piecemeal approach? Right now there are no
>>> bindings for MC, but I wouldn't complain about fixing some of the C code
>>> when the time comes.
>>
>> The lifetime issues affect plain V4L2 video nodes too I'm afraid :-)
>
> Everything under the bindings is unsafe code, so it does not prevent doing upper
> implementation and have other things be memory safe. It just make Rust less
> helpful in some cases (I guess everything across ops).
>
> There is low hanging fruit if some folks are interested. I see legitimate
> benefit in rewriting in rust the JPEG parser, the H.264 reference list
> generator, and maybe VP9 probability update lib. AV1 driver will need a lib to
> reduce duplicates, this could be done straight in Rust (offering a C interface
> of course, so it does not matter if the users are written in rust or C).
Unfortunately I don't think actually replacing the C implementations
will be possible until Rust architecture support is on par with C, which
probably means waiting until gccrs is ready...
We could have both implementations until then (and only use the C one
where Rust doesn't work), but the code duplication has an extra
maintenance cost so it's not free. That's why people are mostly focusing
on drivers first instead of core code.
~~ Lina
Powered by blists - more mailing lists