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

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