On Tue, May 4, 2021 at 11:21 PM Linus Walleij [off-list ref] wrote:

Another argument can be made that for Rust to be
perceived as mature, two independent implementations
should exist anyway.

Many people agree, and in fact it may not be that far away. On related
news, the GCC frontend for Rust is now in Compiler Explorer, e.g.
https://godbolt.org/z/Wjbe5dTTb

I just requested `mrustc` (the Rust transpiler written in C++ for
bootstrapping purposes) to the Compiler Explorer folks to have it
there too.

Fixing proper compilers may take a few years, like
5 or 10. But who cares? We are in it for the long run

I don't think it will take 5 years to see a new frontend (in
particular if only for valid code).

But even if it does, I don't see why we would need to wait for that to
start setting up Rust for the kernel if the decision is made to do so.

In fact, getting into the kernel can be an incentive for a new
frontend to say "we are now able to compile the kernel".

There are also other advantages to start the work now, such as working
out the currently-nightly features we need in the Rust language and
the standard library, getting them stabilized, submitting upstream
fixes (I had to implement a couple small ones), etc.

That way, when the time comes that we announce a minimum Rust stable
version, all that is ready for other frontends too.

But I am not convinced that writing device drivers is the right
thing to use Rust for in the kernel.

That is fair, hopefully the picture will be clearer when we get the
first drivers that talk to real hardware.

There are some stuff in device driver frameworks, such as USB
hierarchies or (battery) charging state machines, that can be
really good to rewrite in Rust. But these rewrites would affect
anything with a USB port for example, including Nios II and
Motorola 68k systems.  So then the compiler support for all
archs is needed first.

I would avoid a rewrite, but similarly to one of the previous points,
I don't see why work cannot already start if a maintainer is keen on
using Rust (and able to maintain both to some degree).

I think right now the right thing for Rust is to work out-of-tree until
there is Rust support for all archs, while encouraging kernel
developers to learn the language.

That would be an option, yes, but if the decision ends up being made
and we are encouraging kernel developers to learn the language, what
do we achieve by keeping things out-of-tree?

In fact, by getting in-tree people, organizations & companies would be
encouraged to give more support sooner rather than later to the LLVM
backends they care about and/or to the GCC frontend for Rust. So, in a
way, it can be a win for those projects too.

Cheers,
Miguel