Date: Thu, 3 Oct 2024 02:55:47 -0600 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org> Cc: qemu-devel <qemu-devel@nongnu.org>, Manos Pitsidianakis <manos.pitsidianakis@linaro.org>, Hanna Reitz <hreitz@redhat.com>, Peter Maydell <peter.maydell@linaro.org>, pkg-qemu-devel@lists.alioth.debian.org, Michael Tokarev <mjt@tls.msk.ru>, 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?= <berrange@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Markus Armbruster <armbru@redhat.com>, Thomas Huth <thuth@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, dvzrv@archlinux.org, anatol.pomozov@gmail.com, Miroslav Rezanina <mrezanin@redhat.com> Subject: Re: Rust BoF and maintainer minutes and planning the roadmap to Rust Message-ID: <CANCZdfpWN%2BnYGLBtMb5xdpFW%2B=iGZ473UhknLN0vW6PyHSQScQ@mail.gmail.com> In-Reply-To: <CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ@mail.gmail.com> References: <871q16fq9c.fsf@draig.linaro.org> <CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <imp@bsdimp.com> wrote: > > > On Thu, Sep 26, 2024 at 8:24=E2=80=AFAM Alex Benn=C3=A9e <alex.bennee@lin= aro.org> > 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 3, 2024 at 2:53=E2=80=AFA= M Warner Losh <<a href=3D"mailto:imp@bsdimp.com">imp@bsdimp.com</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= =3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Sep 26, 2024 at 8:24=E2=80=AFAM Alex = Benn=C3=A9e <<a href=3D"mailto:alex.bennee@linaro.org" target=3D"_blank"= >alex.bennee@linaro.org</a>> wrote:<br></div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex">One output from this discussion should be a clear st= atement that we are<br> going forward with this work and the road map. A rough roadmap might<br> look like:<br> <br> =C2=A0 - 9.2=C2=A0 =C2=A0--enable-rust is available and developers can buil= d with it.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rust devices have -x-device or -rust-dev= ice CLI flags for<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 runtime selection.<br> <br> =C2=A0 - 10.x=C2=A0 rust devices feature complete and migration compatible,= enabled<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by default when rust compiler detected. = No CLI selection<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 required as legacy portions won't be= built. Any partial<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conversions should be behind --enable-pr= ototype-rust configure<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flag.<br> <br> =C2=A0 - 11.x=C2=A0 distros have enough infrastructure to build on supporte= d<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 platforms. Rust becomes a mandatory depe= ndency, old C versions<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of converted code removed from build.<br= > <br> =C2=A0 - xx.y=C2=A0 QEMU becomes a pure native rust program and all C is ex= punged.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We may never get to this point.<br> <br> We should publish the intention and the road map prominently although it<br= > was unclear if a blog post would be the best place vs expanding a<br> section in the developers manual. Perhaps both make sense with a blog<br> post for the statement of intent and rough timeline and the developer<br> manual being expanded with any new rules and standards to follow?<br></bloc= kquote><div><br></div><div>FreeBSD is Tier 1 in rust only for amd64 (x86_64= ). It's Tier 2 for i386 (which</div><div>admittedly is going away) and = Tier 3 for everything else.</div></div></div></blockquote><div><br></div><d= iv>oops, I should have said it's Tier 2 with hosts for amd64, Tier 2 w/= o hosts and</div><div>tier 3 for aarch64 (and everything else). In FreeBSD,= amd64 and aarch64 are</div><div>tier 1 supported=C2=A0platforms and I got = those confused. It is an important difference</div><div>and later in my ema= il I refer to it, so I thought a correction was in order.</div><div>=C2=A0<= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di= v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">T= here was some concern about the missing gaps in the support matrix<br> especially as we support a number of "legacy" TCG backends. While= *-user<br> support is more insulated from the effects of rust conversions due to<br> its relatively low set of dependencies it will still be a problem if we<br> convert the core CPU QOM classes to rust.<br></blockquote><div><br></div><d= iv>Indeed. I have great concerns here, though we've already dropped</di= v><div>32-bit host support for bsd-user. The status of aarch64 support and = rumored</div><div>difficulty getting that rust support upgraded give me pau= se for concern</div><div>because it's a FreeBSD Tier 1 platform. While = it basically works, the lack of</div><div>commitment by the Rust community = is troubling. Even more troubling because</div><div>rust still uses the old= FreeBSD 11 compat syscalls, despite upgraded</div><div>being available for= years at this point (though maybe this info has changed</div><div>in the l= ast month or two, the years long delay in moving off the interfaces</div><d= iv>that the FreeBSD project obsoleted about 8 years ago is troubling on its= own).</div><div>Much of the resistance I'm told (I'm not a big rus= t person, so I have to reply</div><div>on others) has been in the rust team= because they don't have enough familiarity</div><div>with FreeBSD to m= ake any kind of decision so even properly solved issues</div><div>linger in= the official upstream. The FreeBSD project critically depends on</div><div= >bsd-user for its release process, though that dependency so far has been</= div><div>only on x86 and aarch64, both of which work almost all the time, e= ven if</div><div>they aren't Tier 1 rust platforms.</div><div><br></div= ><div>For -system use, this could limit where qemu runs, though to be hones= t</div><div>the only platform I know has users that might be affected runni= ng -system</div><div>might be RISCV.=C2=A0</div><div><br></div><div>There&#= 39;s similar issues with other BSDs, but I've heard even less reliable = information</div><div>about them, so I'll just leave it at that.</div><= div><br></div><div>So a strawman timeline of 2 years strikes me as unrealis= tically agressive</div><div>for it to be an absolute requirement given the = slow rate of change I've seen</div><div>with upstream rust WRT FreeBSD.= At the very least, it would put qemu on</div><div>non-x86/non-aarch64 plat= forms at risk. While not a huge audience, there are</div><div>some users th= ere. The Tier 2 status for Rust at best for FreeBSD is also a</div><div>bit= worrying for elimination of all C or a big reliance on rust in the core th= at</div><div>can't realistically be avoided. I'm not sure this shou= ld gate the start of the rust</div><div>experiment, but I raise it now so a= s that experiment progresses towards production</div><div>people think to t= alk to me or others in the FreeBSD community as they progress.</div><div><b= r></div><div>Warner</div></div></div> </blockquote></div></div> --0000000000001f2eb306238eb936--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpWN%2BnYGLBtMb5xdpFW%2B=iGZ473UhknLN0vW6PyHSQScQ>