Il mar 6 mag 2025, 13:52 Daniel P. Berrangé <berra...@redhat.com> ha scritto:
> > 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. > Yes it did go pretty far. But VMState is where you hit the barrier for a very specific reason: the thing that you want to produce (structs with pointers to other structs) isn't supported by compile time execution until that version, so you're stuck writing C-style code for migration. These structs have been very central to how QEMU does reflection, for more than 15 years, and there's no real workaround for that. It's certainly possible to delay fully safe VMState some more, but perhaps not 2-3 years. 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. > Most of the updates to Meson were done in the first year after switching, because of new features in Meson that were contributed specifically for use in QEMU. For example, "meson test" was improved to include all the features of the preexisting "make check" (and many more), which benefited all users of Meson. Since then we have only had one bleeding edge update in 2023, when Apple messed up their linker's --version and we had to update in order to help our macOS users (issue 1939). Rust support does require more frequent updates to Meson because QEMU is actually quite an early adopter among large C projects. Apart from juggernauts like Firefox or Linux, I can only think of three: librsvg, GStreamer and Mesa. Even Chromium (which builds with GN) only uses it for some vendored third party libraries, with C++ bindings to Rust code. But I can make these updates optional for people that don't --enable-rust; at the same time I have no interest in building a pile of workarounds for those that do. Anyhow while I am contributing Rust-related improvements to Meson, I have no plans, time or ability to contribute to Rust. :) > 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. > I agree. 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've never made exceptions for Python in the sense of requiring a custom Python interpreter. The interpreters we require have always been available in all supported distros. What we did is not using the distro's *sphinx* on enterprise distros whose default Python interpreter was way past EOL. (IMHO shipping in /usr/bin anything that can run user Python code is a mistake, because it conflicts with the idea that /usr/libexec/platform-python is invisible to the user). That came a few years *after* Meson and it happened because it's harder and harder to support both very new and very old versions of Python, especially after EOL. Our desires in that respect conflict very much with how the Python community operates, unfortunately. 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. > I agree. But the Python change is mostly water under the bridge, and the bleeding edge Meson requirements could be made optional for those that don't use Rust, so I don't think it's too bad. For Rust, this submission shows exactly what the benefit would be and the current status of the code shows how far you get without it. I don't want to sneak in anything, I have posted it for transparency and it's up to the community to discuss how to proceed. We can do so at the community call or wait until KVM Forum. Thanks, Paolo > 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 :| > >
