Google is a contributor but you’re going to have a bad time if you think that Google is some monolithic entity. While a part of Google is funding it, other Googlers may be maintainers that are opposed to helping the project (eg look at the article about the rust for Linux maintainer stepping down due to burnout from politics and the comments made my Ted Tso a Google employee against the R4L project).

But yes, R4L is a thing that’s still going on but it’s unrelated to rust in firmware unless you bucket everything Rust together. R4L is adapting Rust and establishing conventions and build systems relevant only to the Linux kernel and that’s not necessarily a whole lot in common with firmware projects which are typically managed and maintained very differently with very different build systems.

Yep, I agree with all that.

One of the really nice parts of the Rust linux project is that the new Rust code is getting a some of the memory management patterns in the C code actually written down rather than just being in the heads of the programmers.

Can you please explain what this means ? Isn't it now just in Rust code instead of C code ? Or is there some design documentation being written around this ?

My understanding is there is a bunch of poorly documented C code that is being translated into Rust using strict types.

This can simplify a bunch when using Rust but also better documents the internals for C.

Translated is really the wrong word here.

Rust bindings for it are being written so you can call the C code from safe rust. The C code still exists and only the api is duplicated into rust.

The convenient side effect of that is that you need to know what constraints you have to enforce to make that memory safe, and generally memory safe here is going to translate to knowing how to properly call the api and enforcing that.

Very little C code is actually being rewritten in rust. None of the core C code that is really at issue here (but, for example, android's binder driver has been rewritten).