qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).