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
[-- Attachment #1 --] On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <imp@bsdimp.com> wrote: > > > On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.bennee@linaro.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. > 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 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 > 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 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 > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <<a href="mailto:imp@bsdimp.com">imp@bsdimp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <<a href="mailto:alex.bennee@linaro.org" target="_blank">alex.bennee@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="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 statement that we are<br> going forward with this work and the road map. A rough roadmap might<br> look like:<br> <br> - 9.2 --enable-rust is available and developers can build with it.<br> rust devices have -x-device or -rust-device CLI flags for<br> runtime selection.<br> <br> - 10.x rust devices feature complete and migration compatible, enabled<br> by default when rust compiler detected. No CLI selection<br> required as legacy portions won't be built. Any partial<br> conversions should be behind --enable-prototype-rust configure<br> flag.<br> <br> - 11.x distros have enough infrastructure to build on supported<br> platforms. Rust becomes a mandatory dependency, old C versions<br> of converted code removed from build.<br> <br> - xx.y QEMU becomes a pure native rust program and all C is expunged.<br> 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></blockquote><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><div>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 platforms and I got those confused. It is an important difference</div><div>and later in my email I refer to it, so I thought a correction was in order.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="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><div>Indeed. I have great concerns here, though we've already dropped</div><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 pause 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 last month or two, the years long delay in moving off the interfaces</div><div>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 rust 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 make 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, even 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 honest</div><div>the only platform I know has users that might be affected running -system</div><div>might be RISCV. </div><div><br></div><div>There'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 unrealistically 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 platforms at risk. While not a huge audience, there are</div><div>some users there. 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 that</div><div>can't realistically be avoided. I'm not sure this should gate the start of the rust</div><div>experiment, but I raise it now so as that experiment progresses towards production</div><div>people think to talk to me or others in the FreeBSD community as they progress.</div><div><br></div><div>Warner</div></div></div> </blockquote></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpWN%2BnYGLBtMb5xdpFW%2B=iGZ473UhknLN0vW6PyHSQScQ>