From nobody Thu Oct 03 08:53:08 2024 X-Original-To: emulation@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XK5756skXz5Xyk8 for ; Thu, 03 Oct 2024 08:53:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XK5750Mt7z43Xm for ; Thu, 3 Oct 2024 08:53:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=23kjS5V6; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::52a) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-7163489149eso569290a12.1 for ; Thu, 03 Oct 2024 01:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1727945600; x=1728550400; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ctF6ZCsxmnjqNoA/TJanV3/QwxKpQtVltx+hHIdWicQ=; b=23kjS5V6vByYpII71RSyUQ3QJfFubkkC1BfSDjvZU5bTwKJYFA1VatPLcynDm/b1qf i92NWAR2bLoN0eAqZm6AlvO1SjCajj0D45nCHBTzErzPllykjHkh4A6oGSdjB18CB7KT IrmL4OnNC9qNU4efQHAcIhZCdrOGYFSp9VTI3CwCrori2NdcW0mnfzzQu9O16hs4Dtc+ Srp3yDaLieoVb2HhV7s8tdR7h9kQ9Zpb2Wr0Jyf68YQmNcYZjcJlxRGPsTCUH1nuczo0 oP5MijpYAFgTown93wIWRQ6uGOSWO4zw2FJQGKlLZrm1mtc64jufiiF+dNSIWJ6PmX48 srdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727945600; x=1728550400; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ctF6ZCsxmnjqNoA/TJanV3/QwxKpQtVltx+hHIdWicQ=; b=uDS3Hzke7oQ3CX0bBWcCqCIG6hlNJUjsV6VHODuCpQZ69KAQtqsUwpIsIRokn7zyd0 uGmtes886LuL6C/vqdZ04xqh/cOWa7D7QiO5ba5UzVK5VjHABFE3e4pkbBC7iw2mkvyM m0WqIfc0j9wmESoLOeaXYIRwxoZFQTXIogo4Q+79ClJdW7+jODxhzQktw8gUjOLkTCPm +eY9IpThe5pUJOQEiB22LFSrVGUiHavRLkQB6/g1ooZLu67wmdXcBdcxSFwV9YDQZQV4 crKiPnkNnzKvvPUKaocZDjcicxrhyGI95EerBhFbtu+fgGKZ6IqRckGquYowOqmbzfJa o8Vw== X-Forwarded-Encrypted: i=1; AJvYcCVp4CKnPvfvhQT3qcvSWkm0znxgyzKLO8NJAg8VQd35nFO6sv1J9IZKgJZMEDtrpkLSfMtqW6m9gTg=@freebsd.org X-Gm-Message-State: AOJu0Yz7xnX2cT8F5f/WNcxFKUlTXEe3UHURzXojGHkp9W7chIDGaI8x vAZrom8gIgLV+SSRtIZWHo4iiILqDk/n0f/D+EAzm+HHN901bAaxBx2AIVkPJSJq9D8OAACDGNu xupfU/Po1w85fdzIcE5hzmD/VuEcoW2hguZfAqQ== X-Google-Smtp-Source: AGHT+IFfTth3oxdU/4J+bD6AxI58/ss5l0oKVUzPUdizv7QVUGXzdw6dSSYxow50QYgzirxB5BLIHC6TpFydaXn451g= X-Received: by 2002:a17:90a:77c4:b0:2e0:74c9:ecea with SMTP id 98e67ed59e1d1-2e184681664mr7494564a91.10.1727945599817; Thu, 03 Oct 2024 01:53:19 -0700 (PDT) List-Id: Development of Emulators of other operating systems List-Archive: https://lists.freebsd.org/archives/freebsd-emulation List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-emulation@FreeBSD.org MIME-Version: 1.0 References: <871q16fq9c.fsf@draig.linaro.org> In-Reply-To: <871q16fq9c.fsf@draig.linaro.org> From: Warner Losh Date: Thu, 3 Oct 2024 02:53:08 -0600 Message-ID: Subject: Re: Rust BoF and maintainer minutes and planning the roadmap to Rust To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: qemu-devel , Manos Pitsidianakis , Hanna Reitz , Peter Maydell , pkg-qemu-devel@lists.alioth.debian.org, Michael Tokarev , ncopa@alpinelinux.org, bofh@freebsd.org, emulation@freebsd.org, virtualization@gentoo.org, dilfridge@gentoo.org, hi@alyssa.is, edolstra+nixpkgs@gmail.com, brad@comstyle.com, =?UTF-8?Q?Daniel_P_=2E_Berrang=C3=A9?= , Paolo Bonzini , Markus Armbruster , Thomas Huth , Stefan Hajnoczi , dvzrv@archlinux.org, anatol.pomozov@gmail.com, Miroslav Rezanina Content-Type: multipart/alternative; boundary="000000000000ab3e0106238eaf04" X-Spamd-Result: default: False [-1.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWELVE(0.00)[23]; FREEMAIL_CC(0.00)[nongnu.org,linaro.org,redhat.com,lists.alioth.debian.org,tls.msk.ru,alpinelinux.org,freebsd.org,gentoo.org,alyssa.is,gmail.com,comstyle.com,archlinux.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; R_SPF_NA(0.00)[no SPF record]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[emulation@freebsd.org]; TAGGED_RCPT(0.00)[nixpkgs]; MLMMJ_DEST(0.00)[emulation@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52a:from] X-Rspamd-Queue-Id: 4XK5750Mt7z43Xm X-Spamd-Bar: - --000000000000ab3e0106238eaf04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2024 at 8:24=E2=80=AFAM Alex Benn=C3=A9e wrote: > One output from this discussion should be a clear statement that we are > going forward with this work and the road map. A rough roadmap might > look like: > > - 9.2 --enable-rust is available and developers can build with it. > rust devices have -x-device or -rust-device CLI flags for > runtime selection. > > - 10.x rust devices feature complete and migration compatible, enabled > by default when rust compiler detected. No CLI selection > required as legacy portions won't be built. Any partial > conversions should be behind --enable-prototype-rust configure > flag. > > - 11.x distros have enough infrastructure to build on supported > platforms. Rust becomes a mandatory dependency, old C versions > of converted code removed from build. > > - xx.y QEMU becomes a pure native rust program and all C is expunged. > We may never get to this point. > > We should publish the intention and the road map prominently although it > was unclear if a blog post would be the best place vs expanding a > section in the developers manual. Perhaps both make sense with a blog > post for the statement of intent and rough timeline and the developer > manual being expanded with any new rules and standards to follow? > FreeBSD is Tier 1 in rust only for amd64 (x86_64). It's Tier 2 for i386 (which admittedly is going away) and Tier 3 for everything else. There was some concern about the missing gaps in the support matrix > especially as we support a number of "legacy" TCG backends. While *-user > support is more insulated from the effects of rust conversions due to > its relatively low set of dependencies it will still be a problem if we > convert the core CPU QOM classes to rust. > Indeed. I have great concerns here, though we've already dropped 32-bit host support for bsd-user. The status of aarch64 support and rumored difficulty getting that rust support upgraded give me pause for concern because it's a FreeBSD Tier 1 platform. While it basically works, the lack of commitment by the Rust community is troubling. Even more troubling because rust still uses the old FreeBSD 11 compat syscalls, despite upgraded being available for years at this point (though maybe this info has changed in the last month or two, the years long delay in moving off the interfaces that the FreeBSD project obsoleted about 8 years ago is troubling on its own). Much of the resistance I'm told (I'm not a big rust person, so I have to reply on others) has been in the rust team because they don't have enough familiarity with FreeBSD to make any kind of decision so even properly solved issues linger in the official upstream. The FreeBSD project critically depends on bsd-user for its release process, though that dependency so far has been only on x86 and aarch64, both of which work almost all the time, even if they aren't Tier 1 rust platforms. For -system use, this could limit where qemu runs, though to be honest the only platform I know has users that might be affected running -system might be RISCV. There's similar issues with other BSDs, but I've heard even less reliable information about them, so I'll just leave it at that. So a strawman timeline of 2 years strikes me as unrealistically agressive for it to be an absolute requirement given the slow rate of change I've see= n with upstream rust WRT FreeBSD. At the very least, it would put qemu on non-x86/non-aarch64 platforms at risk. While not a huge audience, there are some users there. The Tier 2 status for Rust at best for FreeBSD is also a bit worrying for elimination of all C or a big reliance on rust in the core that can't realistically be avoided. I'm not sure this should gate the start of the rust experiment, but I raise it now so as that experiment progresses towards production people think to talk to me or others in the FreeBSD community as they progress. Warner --000000000000ab3e0106238eaf04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 26, 2024 at 8:24=E2=80=AF= AM Alex Benn=C3=A9e <alex.benn= ee@linaro.org> wrote:
One output from this discussion should be a clear statement th= at we are
going forward with this work and the road map. A rough roadmap might
look like:

=C2=A0 - 9.2=C2=A0 =C2=A0--enable-rust is available and developers can buil= d with it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rust devices have -x-device or -rust-dev= ice CLI flags for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 runtime selection.

=C2=A0 - 10.x=C2=A0 rust devices feature complete and migration compatible,= enabled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by default when rust compiler detected. = No CLI selection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 required as legacy portions won't be= built. Any partial
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conversions should be behind --enable-pr= ototype-rust configure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flag.

=C2=A0 - 11.x=C2=A0 distros have enough infrastructure to build on supporte= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 platforms. Rust becomes a mandatory depe= ndency, old C versions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of converted code removed from build.
=C2=A0 - xx.y=C2=A0 QEMU becomes a pure native rust program and all C is ex= punged.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We may never get to this point.

We should publish the intention and the road map prominently although it was unclear if a blog post would be the best place vs expanding a
section in the developers manual. Perhaps both make sense with a blog
post for the statement of intent and rough timeline and the developer
manual being expanded with any new rules and standards to follow?

FreeBSD is Tier 1 in rust only for amd64 (x86_64= ). It's Tier 2 for i386 (which
admittedly is going away) and = Tier 3 for everything else.

There was some concern about the missing gaps in the= support matrix
especially as we support a number of "legacy" TCG backends. While= *-user
support is more insulated from the effects of rust conversions due to
its relatively low set of dependencies it will still be a problem if we
convert the core CPU QOM classes to rust.

Indeed. I have great concerns here, though we've already dropped
32-bit host support for bsd-user. The status of aarch64 support and = rumored
difficulty getting that rust support upgraded give me pau= se for concern
because it's a FreeBSD Tier 1 platform. While = it basically works, the lack of
commitment by the Rust community = is troubling. Even more troubling because
rust still uses the old= FreeBSD 11 compat syscalls, despite upgraded
being available for= years at this point (though maybe this info has changed
in the l= ast month or two, the years long delay in moving off the interfaces
that the FreeBSD project obsoleted about 8 years ago is troubling on its= own).
Much of the resistance I'm told (I'm not a big rus= t person, so I have to reply
on others) has been in the rust team= because they don't have enough familiarity
with FreeBSD to m= ake any kind of decision so even properly solved issues
linger in= the official upstream. The FreeBSD project critically depends on
bsd-user for its release process, though that dependency so far has been
only on x86 and aarch64, both of which work almost all the time, e= ven if
they aren't Tier 1 rust platforms.

For -system use, this could limit where qemu runs, though to be hones= t
the only platform I know has users that might be affected runni= ng -system
might be RISCV.=C2=A0

There&#= 39;s similar issues with other BSDs, but I've heard even less reliable = information
about them, so I'll just leave it at that.
<= div>
So a strawman timeline of 2 years strikes me as unrealis= tically agressive
for it to be an absolute requirement given the = slow rate of change I've seen
with upstream rust WRT FreeBSD.= At the very least, it would put qemu on
non-x86/non-aarch64 plat= forms at risk. While not a huge audience, there are
some users th= ere. The Tier 2 status for Rust at best for FreeBSD is also a
bit= worrying for elimination of all C or a big reliance on rust in the core th= at
can't realistically be avoided. I'm not sure this shou= ld gate the start of the rust
experiment, but I raise it now so a= s that experiment progresses towards production
people think to t= alk to me or others in the FreeBSD community as they progress.
Warner
--000000000000ab3e0106238eaf04--