qemu-devel
[Top][All Lists]
Advanced

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

Re: Rust in Qemu BoF followup 2: Rust toolchain availability


From: Peter Maydell
Subject: Re: Rust in Qemu BoF followup 2: Rust toolchain availability
Date: Thu, 30 Sep 2021 11:30:20 +0100

On Thu, 30 Sept 2021 at 03:21, David Gibson <david@gibson.dropbear.id.au> wrote:
>
> Hi again all,
>
> I've now done.. or at least started... the second part of my followup
> from the KVM Forum BoF on Rust in Qemu.
>
> I've extended the page at https://wiki.qemu.org/RustInQemu with
> information on Rust toolchain availability.  However, I found I had a
> lot more open questions on this one, so there are quite a lot of gaps.

Thanks for doing this work.

I note that we have a new host architecture loongarch64 currently
circling to land. It looks like this is in the "Rust does not have
support for this target" category at the moment.

> In particular:
>  * I haven't so far figured out how to definitively check package
>    information for RHEL & SLES (they're not covered by repology, and
>    RHEL module structure confuses me, even as a RedHatter)
>  * I'm not at all sure what criteria to use to consider something as
>    having "good enough" rustup support, so that information is all
>    blank so far

I guess the answer here is probably "if it has at least the
glibc and kernel minimum versions that are documented as
required for the target-triple in the lists at
https://doc.rust-lang.org/rustc/platform-support.html then
that's 'good enough'".

>  * I've taken a bit of a stab in the dark about what Rust version is
>    recent enough for our purposes (1.31.0).  I strongly suspect we're
>    going to want to move that to something more recent, but I don't
>    know what, which will mean revising a bunch of stuff

Hmm. The more we feel we need features that are from a new
version of Rust the more nervous I get about whether this is
really something we want to jump to just yet. 1.31 is less than
3 years old, which is pretty recent in the context of QEMU's
own distro support policy.

>  * I'm not really convinced that the way I've formatted it is
>     particularly good, but I haven't though of a better alternative.

I guess we might also care about the CPU architecture per distro,
in that even if old version X of the distro supports architecture Y
and rust today supports architecture Y, that doesn't mean that
distro version X's shipped rust supported architecture Y.
But we can probably reasonably say "use rustup" if there are
corner cases like that.

-- PMM



reply via email to

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