Re: [PATCH 00/13] [RFC] Rust support

[Linus Walleij]

On Wed, Apr 28, 2021 at 5:10 AM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> On Tue, Apr 27, 2021 at 1:13 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> >
> > Actually my reply to Wedson brought up a new issue, which is the
> > quality of learning resources and the lack of an equivalent to
> > The C Programming Language book.
>
> I recall having a similar feeling when initially jumping into
> individual chapters of The Rust Programming Language book. I think it
> is intended to be read from cover to cover instead.
>
> There are other resources, see [1]. For instance, there is The
> Embedded Rust Book [2]. Some of those are a WIP, but perhaps others
> can recommend better finished/published books.
>
> In any case, Rust has more features than C, some of them quite unique,
> and they are routinely used, so it does take some time to learn.

No joke, I do try. I thought it would be easier since I have written
a fair share of Haskell in my years but Rust is this hybrid of
imperative and functional that just make things a bit hard
to pin down: is this part functional? is it imperative?
is it object oriented? etc.

But the reference that Robin pointed to is better to read. It
is not as talkative and more to the point. So now I am working
with that.

> > I think a good starting point would be to either fix Rust support in
> > GCC or implement some more important ISAs in LLVM,
> > whichever is easiest. I don't mind having just *one* compiler but
> > I mind having *a* compiler for every arch we support.
> >
> > [...]
> >
> > Portability to old systems and ISAs is a virtue in itself
> > because of the effect it has on code quality, not necessarily
> > for the support itself.
>
> I agree that there are benefits of keeping compiler technology
> flexible, but one cannot force or expect any project (including the
> Linux kernel) to maintain all code forever.
>
> In the end, we need to balance that adaptability against the benefits
> of adding Rust. In particular because nowadays LLVM is able to cover
> the majority of devices that want to run the very latest Linux
> kernels. Thus those benefits apply to most users. If LLVM only
> supported, say, x86_64, I would agree that it would not be enough.
>
> By contrast, compiler flexibility only matters indirectly to users,
> and at some point there are diminishing returns to keeping all
> architectures around.

My values in this regard are 180 degrees opposed to yours.

My attitude to the problem, was I to fix it, would be
"let's go fix a frontend for Rust to GCC, how hard can it be"
rather than trying to avoid that work with this kind of
reasoning trying to one way or other prove that it is not
worth the effort.

A GCC front-end will allow you to run Rust on all Linux
target architectures which is a big win. LLVM can be
expanded with backends for all archs as well but that
seems like a much bigger job to me.

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

The IETF Standards Process (RFC 2026, updated by
RFC 6410) requires at least two independent and
interoperable implementations for advancing a protocol
specification to Internet Standard.

Why should the kernel programming languages have any
lower standards than that?

The C programming language has earned its place thanks
to perseverance of implementing and reimplementing
compilers for it again and again.

Fixing proper compilers may take a few years, like
5 or 10. But who cares? We are in it for the long run
anyway. When I designed the character device interface
for GPIO I said I expect it to be maintained for at least
100 years. This is my honest perspective of things.

Torvalds has this saying (from Edison) that kernel
engineering is 1% inspiration and 99% perspiration.
Well let's live by that and fix those compilers.

When Linux was developed in 1992 C had existed since
1973 so it was 19 years old.

Now Linux is 28 years old and C is 47 years old.

This discussion needs perspective. And we really
cannot have development with a finger constantly
pushing the fastforward button.

> In any case, adding Rust (in particular for "leaf" modules) does not
> imply that we will lose those architectures any time soon.

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

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.

> That would
> take at least several years, and would require quite a few things to
> happen at the same time:
>
>   - That Rust got so widely used in the kernel (because the benefits
> turned out to be important) that maintainers went as far as wanting to
> drop C drivers from mainline for Rust equivalents.
>
>   - That GCC did not get any way to compile Rust (no Rust frontend for
> GCC, no GCC backend for `rustc`, etc.) and, moreover, that the plans
> for that had been dropped.
>
>   - That LLVM did not add support for the missing architectures.
>
> The first point is unlikely any time soon. The second point is
> unlikely, too, given there is funding for that now (and I assume those
> projects will receive more support if Rust lands in the kernel). The
> third point is likely, though.

What about patience?

I am thrilled to hear that GCC is growing Rust support and has funding
to fix a proper front-end. This is what Rust needs in general and
what the kernel needs in particular.

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.

Yours,
Linus Walleij