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