qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
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: Thu, 3 Oct 2024 02:53:08 -0600	[thread overview]
Message-ID: <CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ@mail.gmail.com> (raw)
In-Reply-To: <871q16fq9c.fsf@draig.linaro.org>

[-- Attachment #1: Type: text/plain, Size: 4115 bytes --]

On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> One output from this discussion should be a clear statement that we are
> going forward with this work and the road map. A rough roadmap might
> look like:
>
>   - 9.2   --enable-rust is available and developers can build with it.
>           rust devices have -x-device or -rust-device CLI flags for
>           runtime selection.
>
>   - 10.x  rust devices feature complete and migration compatible, enabled
>           by default when rust compiler detected. No CLI selection
>           required as legacy portions won't be built. Any partial
>           conversions should be behind --enable-prototype-rust configure
>           flag.
>
>   - 11.x  distros have enough infrastructure to build on supported
>           platforms. Rust becomes a mandatory dependency, old C versions
>           of converted code removed from build.
>
>   - xx.y  QEMU becomes a pure native rust program and all C is expunged.
>           We may never get to this point.
>
> We should publish the intention and the road map prominently although it
> was unclear if a blog post would be the best place vs expanding a
> section in the developers manual. Perhaps both make sense with a blog
> post for the statement of intent and rough timeline and the developer
> manual being expanded with any new rules and standards to follow?
>

FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386
(which
admittedly is going away) and Tier 3 for everything else.

There was some concern about the missing gaps in the support matrix
> especially as we support a number of "legacy" TCG backends. While *-user
> support is more insulated from the effects of rust conversions due to
> its relatively low set of dependencies it will still be a problem if we
> convert the core CPU QOM classes to rust.
>

Indeed. I have great concerns here, though we've already dropped
32-bit host support for bsd-user. The status of aarch64 support and rumored
difficulty getting that rust support upgraded give me pause for concern
because it's a FreeBSD Tier 1 platform. While it basically works, the lack
of
commitment by the Rust community is troubling. Even more troubling because
rust still uses the old FreeBSD 11 compat syscalls, despite upgraded
being available for years at this point (though maybe this info has changed
in the last month or two, the years long delay in moving off the interfaces
that the FreeBSD project obsoleted about 8 years ago is troubling on its
own).
Much of the resistance I'm told (I'm not a big rust person, so I have to
reply
on others) has been in the rust team because they don't have enough
familiarity
with FreeBSD to make any kind of decision so even properly solved issues
linger in the official upstream. The FreeBSD project critically depends on
bsd-user for its release process, though that dependency so far has been
only on x86 and aarch64, both of which work almost all the time, even if
they aren't Tier 1 rust platforms.

For -system use, this could limit where qemu runs, though to be honest
the only platform I know has users that might be affected running -system
might be RISCV.

There's similar issues with other BSDs, but I've heard even less reliable
information
about them, so I'll just leave it at that.

So a strawman timeline of 2 years strikes me as unrealistically agressive
for it to be an absolute requirement given the slow rate of change I've seen
with upstream rust WRT FreeBSD. At the very least, it would put qemu on
non-x86/non-aarch64 platforms at risk. While not a huge audience, there are
some users there. The Tier 2 status for Rust at best for FreeBSD is also a
bit worrying for elimination of all C or a big reliance on rust in the core
that
can't realistically be avoided. I'm not sure this should gate the start of
the rust
experiment, but I raise it now so as that experiment progresses towards
production
people think to talk to me or others in the FreeBSD community as they
progress.

Warner

[-- Attachment #2: Type: text/html, Size: 5115 bytes --]

  parent reply	other threads:[~2024-10-03  9:15 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
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 [this message]
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=CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ@mail.gmail.com \
    --to=imp@bsdimp.com \
    --cc=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@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).