Re: [TECH TOPIC] Rust for Linux

Leon Romanovsky
2021-07-06T14:56:23Z

On Tue, Jul 06, 2021 at 04:24:07PM +0200, Miguel Ojeda wrote:
> On Tue, Jul 6, 2021 at 6:30 AM Leon Romanovsky <leon@kernel.org> wrote:
> >
> > 1. The addition of another language to the mix will hurt a lot our
> > ability to refactor code for cross-subsystem changes.
> >
> > Just as an example, there are many changes in DMA/SG areas that are
> > applicable for many drivers. Even simple grep->replace pattern will
> > be harder and longer if it is needed for the drivers that are written
> > in different languages.
>
> In the design we chose, Rust drivers do not call C code directly --
> they go through the abstractions a given subsystem may provide. Thus
> only the abstractions would need to be updated, like any other C
> consumer of the APIs.

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.

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.

>
> > 2. Testing matrix will be duplicated, both in compilation tests and in
> > verification coverage. Even now, there are some kernel subsystems that
> > so much in-love with CONFIG_* options that their combination is slightly
> > tested or not tested at all. So imagine, we will need to recompile
> > everything with Rust too and execute same coverage tests again.
>
> I am not sure I understand this point.
>
> On its own, `CONFIG_RUST` only changes 1 single place currently (the
> addition of a `vsprintf` format specifier).
>
> Moreover, the goal is that Rust is enabled by default for
> architectures that support it. So there would be no need for
> duplication at all.

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.

>
> > And yes, proper testing costs a lot of money, which IMHO better to
> > invest in improving coverage/fixing bugs/tooling instead of adding
> > new language to the pack.
>
> The original RFC includes an overview of advantages and disadvantages of Rust:
>
> https://lore.kernel.org/lkml/20210414184604.23473-1-ojeda@kernel.org/
>
> Rust brings things to the table that less-than-100%-coverage and
> tooling cannot. For instance, UBSAN catches UB, but the safe subset of
> Rust forbids UB statically (assuming unsafe code is sound).
>
> Trying to clarify this sort of thing is why I included the "quick
> introduction of the Rust language" point in the abstract of the tech
> topic -- I think it is worth having a common ground to discuss things
> and getting everybody on the same page.

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

Thanks

>
> Cheers,
> Miguel