Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@linaro.org> wrote:
> What are candidates for conversion?

"Conversion" means "rewrite in Rust" to me. There are other ways of
integrating Rust without converting existing code:

- Writing new subsystems in Rust where there is no existing C code.
- Adding Rust bindings to existing subsystems so that new code (e.g.
device models) can optionally be written in Rust while still allowing
new C code.

Let's speak more broadly about "integrating Rust" rather than
"conversion", which is just one of the ways to use Rust in QEMU.

> Hanna and Stefan were keen to see more use of Rust in the block layer.
> Hanna cautioned that it was hard to find a reasonable starting point for
> the conversion. Originally she had started with the core sub-system but
> it quickly ran into thousands of lines of code which would be hard to
> get well reviewed before switching for such a crucial sub-system. Maybe
> this is an ordering problem and it would make more sense to start with
> individual block drivers first and work up from there.

Hanna's Rust Storage Daemon (basically a Rust version of the QEMU
block layer as an external process) is here:
https://gitlab.com/hreitz/rsd

> Another potential area for conversion was the VirtIO device and
> vhost-user code which could expect to re-use a lot of the crates from
> the rust-vmm project. However this did bring up the point of maintainer
> buy in. Stefan brought up the example of the simpletrace rewrite which
> while it may have brought some advantages he felt he was unable to take
> as a maintainer as he was not familiar with Rust at that point.

Familiarity with Rust was not the issue with simpletrace. I had
already worked on libblkio in Rust and was able to understand the Rust
simpletrace patches.

It was a question of when rewriting in Rust is appropriate. Surprising
maintainers with a rewrite is risky because they may not be convinced
by the rewrite after all the work to write it has been done.

In the case of simpletrace there wasn't a clear benefit to a rewrite:
performance was potentially better in Rust (performance hadn't been a
problem for users though) but usability was impacted by converting a
scriptable Python module to Rust (requiring users to rewrite their
scripts). The rewrite was dropped.

What I tried to express at the Rust BoF was: talk to maintainers
before embarking on a rewrite.

> With relative inexperience there was a concern we could inadvertently
> introduce technical debt in the code base (C-like Rust vs Rusty rust).
> What can we do to mitigate that issue?

My suggestion is that every `unsafe` needs a comment explaining why it
is safe. That increases the cost of using `unsafe` and encourages safe
abstractions.

There are plenty of unidiomatic ways of using Rust, but none are as
bad as sprinkling `unsafe` everywhere (i.e. writing C in Rust) since
that's how undefined behavior is introduced.

Stefan