Re: [PATCH 0/6] Initial Rust V4L2 support

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

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
> 
>