Date: Thu, 3 Oct 2024 02:53:08 -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: <CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ@mail.gmail.com> In-Reply-To: <871q16fq9c.fsf@draig.linaro.org> References: <871q16fq9c.fsf@draig.linaro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <alex.bennee@linar= o.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, 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 <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=AF= AM Alex Benn=C3=A9e <<a href=3D"mailto:alex.bennee@linaro.org">alex.benn= ee@linaro.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">One output from this discussion should be a clear statement th= at 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><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">There 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> --000000000000ab3e0106238eaf04--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoU4stiEDJKOUEpU-ek_tOBHe0rBH3G9S2Wymc8jHKzCQ>