Re: [TECH TOPIC] Rust for Linux

[Linus Walleij <linus.walleij@linaro.org>]

On Tue, Jul 6, 2021 at 4:30 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:

> In other words, what we are doing is "abstract" the C APIs into Rust
> APIs that can ensure as many invariants as possible statically, using
> Rust facilities for that. Thus Rust is one more consumer of the C
> APIs.

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.

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?

Yours,
Linus Walleij