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. And for Debian that means waiting until July 2027 before making Rust mandatory, and for Ubuntu that's April 2028 based on the current situation. I hope that the effort proves itself either valid or unviable in less than 2-3 years. :) 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. 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. [1] https://rustc-dev-guide.rust-lang.org/building/bootstrapping/what-bootstrapping-does.html#complications-of-bootstrapping > If we're re-writing C devices in Rust, we need to be able to promptly > drop the C impl once the Rust impl is feature complete. Keeping 2 impls > is a general maint burden, as well as an ongoing vmstate compatibility > danger if a change in one impl is not matched by an identical change > in the other impl. I agree. One more reason why "Let's Rewrite It In Rust" is more of a necessary evil to bootstrap the creation of bindings, and not a good idea in general. > IMHO having Rust declared supported in QEMU should be aligned with being > able to drop C impls of any ported devices. I agree in principle, though theory and practice may diverge. Paolo
