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: Alex Bennée
Subject: Re: [RFC PATCH v4 2/7] rust: add bindgen step as a meson dependency
Date: Tue, 09 Jul 2024 15:23:04 +0100

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.

I was going to say Bookworm has now superseded Bullseye which will reach
its release + 3 year support point in August. However the version you
mention in the Bookworm one!

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

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



reply via email to

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