Re: [TECH TOPIC] Rust for Linux

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

I think the point is that if a C API that has a Rust abstraction built
on top changes, then the Rust API exposed by abstraction may have to
change, so all Rust code that use it would need to be updated too. I
dread to think how we could do large refactoring if we can't use
Coccinelle for Rust code.

> > 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.
> 
> > 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.

-- 
Regards,

Laurent Pinchart