On Mon, Sep 30, 2024, 06:24 Alex Bennée <alex.ben...@linaro.org> wrote:
> Stefan Hajnoczi <stefa...@gmail.com> writes: > > > On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.ben...@linaro.org> > wrote: > <snip> > >> 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. > > Apologies for misrepresenting the issue there. My notes obviously didn't > capture that nuance. No worries. Thanks for taking notes! Stefan > > > 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. > > Yes this is the I think the key takeaway because the project would not > be able to absorb a bunch of drive-by rust rewrites from well meaning > contributors. > > >> 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 > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro >
