Re: [TECH TOPIC] Rust for Linux

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Tue, Jul 6, 2021 at 8:27 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> This reasoning assumes that Rust is in the "leafs" of the kernel, if
> such a thing even exists, and device drivers have been mentioned.
>
> If we want to *write* a subsystem in Rust then of course it will
> go the other way: Rust need to expose APIs to C. And I assume
> the grand vision is that after that Rust will eat Linux, one piece
> at a time. If it proves better than C, that is.

In general, I would avoid exposing Rust subsystems to C.

It is possible, of course, and it gives you the advantages of Rust in
the *implementation* of the subsystem. However, by having to expose a
C API, you would be losing most of the advantages of the richer type
system, plus the guarantees that Rust bring as a language for the
consumers of the subsystem.

In any case, I agree it is a good idea to make things as smooth as
possible for interop in both directions. In that regard, for instance,
I presented a `[[safe]]` attribute in the C committee, and while it
did not make it, I hope to get things like that into Clang and GCC.

> The leaf nodes imagined as a starting point is some device
> driver subsystem where individual drivers for that subsystem
> can be written or rewritten in Rust, correct?
>
> And I asked very pointed questions as to whether device drivers
> is really a good place to start.
>
> If the whole rationale with doing device drivers first is strategic,
> not necessarily bringing any benefits to that device driver
> subsystem but rather serving as a testing ground and guinea
> pig, then that strategy needs to be explicit and understood
> by everyone. So while we understand that Rust as
> all these $UPSIDES doing device drivers first is purely
> strategic, correct? I think the ability to back out the whole
> thing if it wasn't working out was mentioned too?

So let me try to clarify the whole "leaf modules" thing.

It is possible to rewrite code in Rust and to also write Rust code and
expose it to C. It is also possible to write non-leaf modules in Rust.

However, the key is that the moment you go back from Rust to C, you
would be losing some of the advantages of Rust, such as the rich type
system, and the ability to write safe code (since C does not have it).

So, the current design is having Rust as a consumer of C APIs,
transform those into Rust APIs, and then Rust modules consume those
APIs. That is:

  C APIs --> Rust abstractions --> Rust modules

Now, nothing prevents you to write a Rust subsystem from scratch --
and in fact, that would be ideal. But if you want to make that
subsystem available back to C, then you are losing part of the appeal
(for the C modules only, of course).

That is why we say it is best for "leaf modules", in the sense that it
is Rust code that uses Rust APIs only. Whether those APIs come from a
new Rust-only subsystem or from some abstractions based on C APIs is
not very important.

Cheers,
Miguel