From nobody Thu Oct 03 08:55:47 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 4XK5B84ys0z5Y0M3 for ; Thu, 03 Oct 2024 08:56:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 4XK5B74SrKz43td for ; Thu, 3 Oct 2024 08:55:59 +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="gLp/3/bP"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::52f) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-7db0fb03df5so469139a12.3 for ; Thu, 03 Oct 2024 01:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1727945758; x=1728550558; 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=MwoKLbjiWk5W2MOxtv+/pJ1HZ7kuDq+4CZj2XYWI1CE=; b=gLp/3/bPue7iDZgDQ2IrpmvCZqvTKAyoT3C976H8emXGELQWHYafMv4G9BIDO453Sw Wk+MPZ93NuvxCdODfwCx9XoH8UapOPXmiftIU93DRWy2uuZ6pbGPo+beYUbB/D6A0NHS ErEJTeYiacXneYVDmTyT36tGJYvRD0hgGjJ6x708JWJfEylp+lFE0JISwgVyuqdyQ3tU LmY3lkHvRladDDlORHNHoDxabFRdfihP8qmCMVXUT4Y+OWDWpAONPEWlrTcEH6rE8t6z Wcij9ucBx4lSf0bl2vUyYDUXggTs9P88MfQ1N2V5LbyIcIgUbF0ApYoH0A1Ucs6MCjj0 /D6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727945758; x=1728550558; 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=MwoKLbjiWk5W2MOxtv+/pJ1HZ7kuDq+4CZj2XYWI1CE=; b=BK8c0sXi8394WnzzH5fRQyYTfsw4KpJV1gdrAWTYHxVpZ6wQyr4Cr95FYMaHjhs/MZ FtTTD06YNLqnIEbiQWNcws8rp2t2ykMjYObdCEexvQQ+DkNAvT5oLUKyIG1y5OPi4gKy Sr77eg0MwIavD95KN345naYtHCWFrQe4mMuVLJ9ZLTNJcvGJn9f3b7KdNU3E3MInp6rH mIN5mYLbrbb7dj1vKZz7BkQ1s+PbFkHm6/pwJ4EXKymlMloA92BqhbJwJfK9nd7rhg4G 0Flmly0Bf+XWiIGSGt6yueJ/kYVb2r3IuC+CZlSJxcZLv0xCxOXVYVQWdOyG3CfMzofu hIJg== X-Forwarded-Encrypted: i=1; AJvYcCWdGgC+l6yaNb2L5p8bhshnJnSJVWSv1abolSx+iYn+xP+5ZKQa63aM2/FnCtg0s3t8j/dxEv5tmO4=@freebsd.org X-Gm-Message-State: AOJu0Yx1IQJ6GzbBMD7oXzpj/3bWEbYxRZkUkAJ8BIozryNK/t89RkWt eg6qp1LNiWo7Kqo/NhrvxZ7SSw/F3+IXE4jbofOnK9ruMRbU2rwD0ckBevIFnhbtIiFFBsaRP1Q H5LXxGo/dwT/Ty8en9e+F7gfsgJm8ev4IN9UnlQ== X-Google-Smtp-Source: AGHT+IGzfRDiCREnIh1eVZNS0aIXd6paZQTQGY3XjjAmlRtRLFiVsWAGuXzK4cECVmkwMNk2pUU5hPz+r1kSe3MYbbk= X-Received: by 2002:a17:90a:be10:b0:2e0:7b2b:f76 with SMTP id 98e67ed59e1d1-2e18468cc49mr8127290a91.19.1727945758413; Thu, 03 Oct 2024 01:55:58 -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: From: Warner Losh Date: Thu, 3 Oct 2024 02:55:47 -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="0000000000001f2eb306238eb936" 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_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; 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::52f:from] X-Rspamd-Queue-Id: 4XK5B74SrKz43td X-Spamd-Bar: - --0000000000001f2eb306238eb936 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 3, 2024 at 2:53=E2=80=AFAM Warner Losh wrote: > > > 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, enable= d >> 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. > oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/o hosts and tier 3 for aarch64 (and everything else). In FreeBSD, amd64 and aarch64 are tier 1 supported platforms and I got those confused. It is an important difference and later in my email I refer to it, so I thought a correction was in order= . > 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 rumor= ed > difficulty getting that rust support upgraded give me pause for concern > because it's a FreeBSD Tier 1 platform. While it basically works, the lac= k > of > commitment by the Rust community is troubling. Even more troubling becaus= e > rust still uses the old FreeBSD 11 compat syscalls, despite upgraded > being available for years at this point (though maybe this info has chang= ed > in the last month or two, the years long delay in moving off the interfac= es > 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 o= n > 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 > seen > 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 a= re > 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 o= f > 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 > --0000000000001f2eb306238eb936 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 3, 2024 at 2:53=E2=80=AFA= M Warner Losh <imp@bsdimp.com> = wrote:


On Thu, Sep 26, 2024 at 8:24=E2=80=AFAM Alex = Benn=C3=A9e <alex.bennee@linaro.org> wrote:
One output from this discussion should be a clear st= atement that 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.

oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/= o hosts and
tier 3 for aarch64 (and everything else). In FreeBSD,= amd64 and aarch64 are
tier 1 supported=C2=A0platforms and I got = those confused. It is an important difference
and later in my ema= il I refer to it, so I thought a correction was in order.
=C2=A0<= /div>
T= here 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
--0000000000001f2eb306238eb936--