On 9/11/25 12:04, Peter Maydell wrote:
On Mon, 8 Sept 2025 at 11:53, Paolo Bonzini <[email protected]> wrote:
This includes:
- bumping MSRV to 1.83.0 to support const_refs_to_static
- Zhao's safe, builder-based implementation of migration callbacks
- Manos's qdev properties macro. While bit-based properties are
not yet supported, that's a small change overall.
- the Rust crate split from Marc-André
- adding proc macro aliases in individual crates, also from Marc-André
I'm still not convinced about having "bql" depend on "migration",
but I am convinced by the crate split between "util" and "bql",
so we can move the implementation of VMState from "bql" to
"migration" later if needed.
For the purpose of getting this in as an easy-to-use base for future
development, I'm disabling CI from Debian and Ubuntu. The plan is:
- that Debian will require trixie to enable Rust usage
- that Ubuntu will backport 1.83 to its 22.04 and 24.04 versions
(https://bugs.launchpad.net/ubuntu/+source/rustc-1.83/+bug/2120318)
- that Marc-André or someone else will add Rust to other CI jobs
How far into the future does moving to 1.83.0 push our
"we can enable rust and make it mandatory" point? I was
hoping we would be able to do that sometime soon but this
sounds like we're going to be still a long way out from that :-(
Sorry for not seeing the question, the good news is that it doesn't push
it by much, if at all. Debian bookworm has even updated rustc-web last
month to 1.85.0 (say thanks to Firefox), so the only remaining straggler
is Ubuntu and they're working on it.
As far as technical blockers go, Marc-André has a couple fixes pending
in Meson, and of course tracing support is still in flight. But we
could enable it for 10.2 in CI and 11.0 in configure.
The bad news is that enabling Rust by default is a bit like a point of
no return and, in that respect, other factors may matter more than
distro support:
* Community support: it's a lot of new code to deal with, and we're not
Linux.
* What's the killer app: DMA support may take a bit longer, so right now
Rust is limited to very simple devices for which memory safety is not a
primary issue. Could it be BQL-free interrupts, where even simpler
devices like interrupt controllers could benefit from a more picky compiler?
* Dependency on Meson work: this is something that Zhao and I didn't
have time to go through, but right now adding a Rust device is *a lot*
more verbose than adding the corresponding Rust device. For day to day
work it's not a huge deal, as the verbosity is a minor issue while we
have a handful of Rust devices. Furthermore, I have plans to improve
Meson in that respect, so that it understands more of the Rust
conventions, and we've already structured a lot of the Rust code with an
eye towards those future versions of Meson. The problem is that for the
most part of 2026 we'll be bumping the minimum supported *Meson* version
relatively quickly. Right now we only bump it for --enable-rust, but
the picture changes if Rust is enabled by default or even hard-required.
Let's talk about it on the community call, since we didn't make it at
QEMU Summit.
Paolo
