All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: peter.maydell@linaro.org, emaste@freebsd.org, slp@redhat.com,
	cohuck@redhat.com, richard.henderson@linaro.org,
	qemu-devel@nongnu.org, f4bug@amsat.org, hreitz@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com,
	marcandre.lureau@redhat.com, sgarzare@redhat.com,
	alex.bennee@linaro.org, imp@bsdimp.com, brad@comstyle.com
Subject: Re: Rust in Qemu BoF followup 2: Rust toolchain availability
Date: Thu, 7 Oct 2021 12:14:05 +1100	[thread overview]
Message-ID: <YV5J3WapCN9bfg5w@yekko> (raw)
In-Reply-To: <YVWVNxKQVEQflD0d@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On Thu, Sep 30, 2021 at 11:45:11AM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 30, 2021 at 11:59:42AM +1000, David Gibson 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.
> > 
> > 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)
> 
> Don't worry about RHEL/SLES directly wrt repology.
> 
> For RHEL, just use corresponding CentOS as a proxy
> 
> For SLES, just use corresponding openSUSE version as a proxy

That makes sense, I've updated the table accordingly.

> >  * 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'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
> 
> Our platform support matrix defines what distros we target.
> 
> IOW we would have a strong preference for a rust version that is present
> in those distros. Essentially tests/docker/dockerfiles/*.Dockerfile
> need to be able to pull in the rust packages from the distro, if
> we are to make it mandatory.

Works for me.  Let's definitely *not* be like Kata, which installs Go
& Rust from upstream binaries, and builds qemu & a guest kernel from
source in its CI runs.

> If rust is to be strictly optional, then we have way more flexibility
> in choosing the version. We do not need to cover all distros in the
> support matrixk *provided* the rust is only used for new functionality
> and we're not introducing it as a dependancy for existing functionality.

Right, but part of the point of this exercise is seeing if we can make
this mandatory, so that's the perspective I'm working from.

> ie existing features previously released must keep working across all
> distros in the matrix. new features from a release can set a higher
> bar, since by definition it can't regress existing usage.
> 
> 
> Regards,
> Daniel

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2021-10-07  1:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  1:59 Rust in Qemu BoF followup 2: Rust toolchain availability David Gibson
2021-09-30 10:30 ` Peter Maydell
2021-10-04  6:01   ` David Gibson
2021-09-30 10:45 ` Daniel P. Berrangé
2021-10-07  1:14   ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YV5J3WapCN9bfg5w@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=brad@comstyle.com \
    --cc=cohuck@redhat.com \
    --cc=emaste@freebsd.org \
    --cc=f4bug@amsat.org \
    --cc=hreitz@redhat.com \
    --cc=imp@bsdimp.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sgarzare@redhat.com \
    --cc=slp@redhat.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.