[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75d9d50fd0e6858ee05a3f2799028b8dc846ec93.camel@collabora.com>
Date: Mon, 01 May 2023 16:19:35 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Asahi Lina <lina@...hilina.net>,
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
Le mardi 02 mai 2023 à 05:17 +0900, Asahi Lina a écrit :
> 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.
Didn't know that, let's postpone this idea then.
thanks,
Nicolas
>
> ~~ Lina
>
>
Powered by blists - more mailing lists