Re: [TECH TOPIC] Rust for Linux

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

On Tue, Jul 6, 2021 at 4:56 PM Leon Romanovsky <leon@kernel.org> wrote:
>
> In such case, I see no easy way to do refactoring. Many (at least for me)
> refactoring changes are not simple sed commands, but more comprehensive
> deep dive into the code which requires to see the actual API usage.

(Also answering to Laurent's)

Yes, of course, that is why we should avoid having Rust abstraction a
subsystem that have maintainers that actually want to have Rust
drivers, i.e. see my reply to James:

"""
Initially, our plan is to work with
subsystem maintainers that do want to start providing a Rust API for
their subsystem. Then they can maintain drivers using such API.

We definitely do not want to have drivers written for a particular
subsystem if nobody is able to review (or even write) the Rust
abstractions for that particular subsystem.
"""

> Even for the simple cases, where someone changes return value type, he/she
> will need to update the logic in the driver. How will abstractions help us here?
>
> IMHO, even worse, people will be less willing to change in-kernel APIs
> because of such abstractions.

The abstractions help because you would only need to change things
there, vs. in all the Rust drivers.

Of course, if it is such a heavy change that new concepts themselves
appear/disappear, then that does not help -- but that is why we should
avoid abstracting what nobody will maintain (see the previous point
for that).

> My point is that we have a customers who run upstream/stable/distro kernels
> on old systems which we need to support. The default CONFIG_RUST=y in .config
> is nice, but most users won't get it or enable it.
>
> So we will need CONFIG_RUST=n to make sure that code for the customers
> work and we will need CONFIG_RUST=y to make sure that at least
> compilation passes.

Ah, I think I see where the confusion comes from. The idea is that if
we are to have Rust as an actual second language, then `CONFIG_RUST`
is enabled by default. Or, putting it another way, `CONFIG_RUST` will
go away at some point.

IIRC this is what Linus wanted -- for the moment the option is there
because we thought it would give a bit of freedom to folks in case
they consider it too experimental for their purposes, plus it allowed
us to allow Rust-enabled kernels built with GCC (which are a hack).

But we can definitely take it out already if kernel folks prefer to
reduce the matrix already (in which case, we will just remove
GCC-built kernels support or put *that* under a different flag).

> Thanks for the summary, I just disagree with the punch line:
>  "the advantages of using Rust outweighs the cost".

That's fair, but you said you didn't know what the advantages are at
the top of your message, so you cannot really tell if they outweigh or
not the cost ;P

Cheers,
Miguel