qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency


From: Paolo Bonzini
Subject: Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency
Date: Tue, 9 Jul 2024 14:28:38 +0200

On Tue, Jul 9, 2024 at 2:09 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>  * what is the actual baseline requirement? We definitely want
>    to support "using rustup on an older system" (should be no
>    problem) and "current distro building QEMU using the distro's
>    rust", I assume. It would certainly be nice to have "building
>    QEMU on the older-but-still-in-our-support-list distro releases
>    with that distro's rust", but this probably implies not just
>    a minimum rust version but also a limited set of crates.

I don't think limiting ourselves to the set of crates in the distro is
feasible. It's not the way the language works, for example I tried
checking if the "cstr" crate exists and I didn't find it in Debian.

We can define a known-good set of versions:
* either via Cargo.lock (i.e. recording the versions and downloading
them) or by including sources in the tree
* at any time in qemu.git, at branching time (three times a year), or
on every release

(That's six possibilities overall).

>    I think (but forget the details) that some of what we've done
>    with Python where we accept that the older-but-still-supported
>    distro will end up taking the "download at build time" path
>    in the build system might apply also for Rust.

Yes, and --without-download may be changed to the "--frozen" flag of cargo.

>  * what, on the Rust side, is the version requirement? Presumably
>    there's some features that are pretty much "we really need
>    this and can't do without it" and some which are "this would
>    be pretty awkward not to have but if we have to we can implement
>    some kind of fallback/alternative with a TODO note to come
>    back and clean up when our baseline moves forwards".

Here are the stopping points that I found over the last couple weeks:

1.56.0: 2021 edition
1.59.0: const CStr::from_bytes_with_nul_unchecked (needed by cstr
crate, see below)
1.64.0: std::ffi::c_char
1.65.0: Generic Associated Types
1.74.0: Clippy can be configured in Cargo.toml
1.77.0: C string literals, offset_of!

I think 1.59.0 is pretty much the lower bound. Not having offset_of!
will be a bit painful, but it can be worked around (and pretty much
has to be, because 1.77.0 is really new).

As far as I understand, Debian bullseye has 1.63.0 these days and it's
the oldest platform we have.

Paolo

> At that point we have more information to figure out what
> if any tradeoff we want to make.
>
> thanks
> -- PMM
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]