On Tue, May 06, 2025 at 12:54:38PM +0200, Paolo Bonzini wrote: > On Tue, May 6, 2025 at 11:49 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > > [...] If Rust is missing or old, "enable > > > > all devices written in Rust" will fail compilation (e.g. Kconfig would > > > > fail for ARM/x86 targets due to unsatisfiable CONFIG_PL011); > > > > "enable Rust" will simply pick the C version of the PL011 and HPET > > > > devices. > > > > I don't really like this because it perpetuates a state where we have > > parallel implementations of devices that have to be kept in sync. > > Me neither (see for example the Meson transition which avoided > parallel implementations at all costs). > > On the other hand, this series shows that it's hard to have a baseline > version earlier than 1.83. The bindings got pretty far while > supporting older versions, and the few hacks needed were nice testbeds > for the build system and the procedural macro infrastructure, but the > improvements that const_refs_to_static provides for reflection are > just too big.
Admittedly I'm not actively working on the QEMU Rust code, but to me to feels the opposite - we've shown it is possible to write useful Rust code with the older version baseline. It may not be the ideal way we want the code to look, but that's a tradeoff we can make. I very much worry that at any point in time there is *always* going to be something in a newer Rust that is very attractive to use, so we end up on a slippery slope where we're always going to be chasing the latest version to get a better way. We've had the same situation with Meson where we initially set a temporary newer baseline to get some critical features we could not do without, and now have ended up in a situation where we are continually pushing newer & newer versions, because there is always something attractive in the new release. > Now, it's certainly not the only possibility: > > 1) If someone contributes devices that are written in Rust then we > could just drop the PL011 and/or HPET sample device. That's a pity but > they would survive in git history and could be resurrected later. IMHO for Rust in QEMU we should be targetting both new features and existing feature ports - excluding existing feature ports would be tieing one of our hands behind our back limiting the potential benefits we can see. > 2) Using RUSTC_BOOTSTRAP[1] allows enabling unstable features even in > versions older than 1.83. Disadvantage: build system changes that will > be obsolete soon(ish), plus the relevant compiler code obviously > wasn't as tested as after stabilization. I'd prefer to avoid that, but > hey---Linux does it. > > 3) Affected distros could use RUSTC_BOOTSTRAP themselves if they want, > while upstream QEMU would only support rustup toolchains for Debian > bookworm and Ubuntu up to 24.10. This only requires > tests/lcitool/refresh changes, the disadvantage is that the project > would renege on the general promise that we make on platform support. Yes, this increasing defeats the benefit of defining our distro target. We wanted to set a clear baseline that we could unambiguously target, to give clarity to both users & contributors on when we could/ would impose new version requirements. We've made exceptions for python, and then meson, and now Rust. We can rationalize it is as "users only need to do x, y & z to get newer stuff", but as we make more & more exceptions, this is a game of death by a 1000 cuts. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
