[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/16] rust: allow older versions of rustc and bindgen
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH 00/16] rust: allow older versions of rustc and bindgen |
Date: |
Fri, 18 Oct 2024 14:31:26 +0100 |
User-agent: |
Mutt/2.2.12 (2023-09-09) |
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)
IOW, we're deciding between
* creating a bit of rust technical debt in the immediate
term, in order to enable rust by default sooner
vs
* avoiding Rust technical debt, but delaying ability to
enable rust by default.
We could consider all C code to be technical debt though,
and if we don't have Rust by default we'll continue adding
yet more C code. IOW, option is just moving the debt from
Rust back to C, which is arguably worse on balance.
Personally I tend towards quicker adoption of Rust, despite
the need for short term workarounds, as they'll disappear
again reasonably quickly.
> 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.
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 ?
> Second,
> because the series is missing the CI updates to actually ensure that
> these minimum versions keep working.
On the last point, see
https://lists.nongnu.org/archive/html/qemu-devel/2024-10/msg02688.html
with that series, it should be just a matter of adding '--enable-rust'
in a few key jobs.
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 :|
- Re: [PATCH 12/16] rust: allow version 1.63.0 of rustc, (continued)
[PATCH 13/16] rust: do not use TYPE_CHARDEV unnecessarily, Paolo Bonzini, 2024/10/15
[PATCH 14/16] rust: do not use --no-size_t-is-usize, Paolo Bonzini, 2024/10/15
[PATCH 15/16] rust: do not use --generate-cstr, Paolo Bonzini, 2024/10/15
[PATCH 16/16] rust: allow older version of bindgen, Paolo Bonzini, 2024/10/15
Re: [RFC PATCH 00/16] rust: allow older versions of rustc and bindgen, Kevin Wolf, 2024/10/18
Re: [RFC PATCH 00/16] rust: allow older versions of rustc and bindgen,
Daniel P . Berrangé <=