Am 18.10.2024 um 17:43 hat Paolo Bonzini geschrieben: > On 10/18/24 15:31, Daniel P. Berrangé wrote: > > On Tue, Oct 15, 2024 at 03:17:18PM +0200, Paolo Bonzini wrote: > > > On top of this, the required version of bindgen is still too new > > > for Debian 12 and Ubuntu 22.04. This is fixed by the last four patches. > > > > > > This is an RFC for two reasons. First, because it would be a valid > > > decision to delay enabling of Rust until at least some of these > > > features are available in all supported distros. > > > > Lets say we maximise our back compatibility today, and have to > > carry some sub-optimal code patterns. > > > > 1, 2, 3, 4 years down the lines, we can gradually eliminate > > those undesired code patterns / workarounds, as older distros > > naturally age-out of our matrix. After 4 years our entire > > matrix will have cycled, so we're not needing to carry this > > debt for very long (4 years is not long in the context of a > > project like QEMU which has been going several decades) > > I agree, for what it's worth. > > > Personally I tend towards quicker adoption of Rust, despite > > the need for short term workarounds, as they'll disappear > > again reasonably quickly. > > Yes, especially since (as Kevin pointed out) most of the workarounds are > okay in terms of maintainability. If the worst is "if let", and it only > occurs in a dependency, we're in a good place overall.
s/if let/let else/ "only occurs in a dependency" is probably not the right argument while we haven't really started writing our own Rust code. If it were available, we would probably use it in new code. But even without that, the conclusion is the same, of course: This doesn't prevent implementing anything and is far from being a show stopper. I'm in favour of anything that lets up keep the phase of duplication as short as possible if it doesn't severly limit what we can do. And I don't see anything in this series that would do that. > > > Another possibility > > > could be to accept Rust 1.64.0 but require installing a newer bindgen > > > (0.66.x for example) on those two distros with an older release. > > > > How difficult is it to get newer 'bindgen' installed on these > > platforms ? The audience here is not so much distros trying to > > package new QEMU, as that's ony relevant for new distro, but > > rather it is end usrs/contributors building QEMU for themslves. > > Very simple - "cargo install bindgen-cli", as already seen in the > fedora-rust-nightly container's Dockerfile (note: building QEMU does _not_ > need cargo). In fact we could in fact do it via libvirt-ci, and it's quite > possible that MacOS or some BSDs will need it. > > Personally I'd be okay with allowing Debian 12 but not Ubuntu 22.04, for > various reasons: > > - Ubuntu 22.04 has a new rustc and an old bindgen---so it's really just > laziness. > > - any workarounds for Debian 12 would last shorter, and anyway > > - Debian 12 has the really important feature (--allowlist-file), whereas the > lack of --generate-cstr is only annoying. > > > Can it be done automagically in the same way we "do the right thing" > > with the 3rd party crates we depend on, or is bindgen special in > > some way that makes it more inconvenient for users ? > > bindgen is special in that it has a metric ton of indirect dependencies, > which we'd all have to write a meson.build for (by hand). :/ If configure errors out with a message "Please run 'cargo install bindgen-cli'" and that is really enough to make it build, I think that should be enough to be counted as supporting the distro. Kevin
