From: "Alex Bennée" <alex.bennee@linaro.org>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
"Hanna Reitz" <hreitz@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
pkg-qemu-devel@lists.alioth.debian.org,
"Michael Tokarev" <mjt@tls.msk.ru>,
ncopa@alpinelinux.org, bofh@freebsd.org, emulation@freebsd.org,
virtualization@gentoo.org, dilfridge@gentoo.org, hi@alyssa.is,
edolstra+nixpkgs@gmail.com, brad@comstyle.com,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
dvzrv@archlinux.org, anatol.pomozov@gmail.com,
"Miroslav Rezanina" <mrezanin@redhat.com>
Subject: Re: Rust BoF and maintainer minutes and planning the roadmap to Rust
Date: Mon, 30 Sep 2024 11:23:58 +0100 [thread overview]
Message-ID: <87y139o2wx.fsf@draig.linaro.org> (raw)
In-Reply-To: <CAJSP0QVB+e1JSyQ3iMRivyh=ufyDkz12AESvJhoPnYJEnt9eug@mail.gmail.com> (Stefan Hajnoczi's message of "Thu, 26 Sep 2024 11:03:40 -0400")
Stefan Hajnoczi <stefanha@gmail.com> writes:
> On Thu, 26 Sept 2024 at 10:24, Alex Bennée <alex.bennee@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.
> 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
next prev parent reply other threads:[~2024-09-30 10:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-26 14:23 Rust BoF and maintainer minutes and planning the roadmap to Rust Alex Bennée
2024-09-26 15:03 ` Stefan Hajnoczi
2024-09-30 10:23 ` Alex Bennée [this message]
2024-09-30 10:51 ` Stefan Hajnoczi
2024-09-26 16:43 ` Daniel P. Berrangé
2024-09-27 7:28 ` Markus Armbruster
2024-10-22 11:55 ` Paolo Bonzini
2024-09-27 2:06 ` Junjie Mao
2024-10-03 8:53 ` Warner Losh
2024-10-03 8:55 ` Warner Losh
2024-10-03 9:56 ` Alex Bennée
2024-10-03 11:29 ` Michael Tokarev
2024-10-14 22:45 ` Warner Losh
2024-10-15 7:23 ` Alex Bennée
2024-10-03 9:53 ` Daniel P. Berrangé
2024-10-03 10:04 ` Warner Losh
2024-10-03 10:58 ` Daniel P. Berrangé
2024-10-22 11:10 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y139o2wx.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=anatol.pomozov@gmail.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=bofh@freebsd.org \
--cc=brad@comstyle.com \
--cc=dilfridge@gentoo.org \
--cc=dvzrv@archlinux.org \
--cc=edolstra+nixpkgs@gmail.com \
--cc=emulation@freebsd.org \
--cc=hi@alyssa.is \
--cc=hreitz@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=mjt@tls.msk.ru \
--cc=mrezanin@redhat.com \
--cc=ncopa@alpinelinux.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pkg-qemu-devel@lists.alioth.debian.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=virtualization@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.