Lines by C vs Rust

Considering Linux's design, it very much is "real kernel" code, which was one of the main reasons Rust for Linux happened. Not to mention things like Binder, which is as critical as you can get for the systems that use it (functionality-, security- and performance-wise).

I suspect you may be referring to (currently) non-loadable, non-configurable features. The limitation for those, as you say, is the toolchain support, but if the relevant maintainers were to deem maintaining a duplicate implementation worth it, then it could technically be done today.

> Thankfully, gccrs has it as a goal for this year to compile the Linux kernel and LWN has it as one of their 2026 predictions.

There is another way as well, `rustc_codegen_gcc`, which already back in Kangrejos 2022 managed to build the kernel. It is still not production ready, but it does boot a x86_64 kernel with Rust code running on it.

Having said that, even if either GCC Rust or `rustc_codegen_gcc` become ready this year (even for several architectures), we will likely want to wait until the packages are in some distributions and so on.

But, yes, if they at least become ready for a major architecture, which is our hope for this year or the next, then that is a very strong signal, and it could easily mean that more maintainers decide to use Rust for their next feature, or perhaps even to maintain parallel implementations.