On Thu, Oct 3, 2024 at 2:53 AM Warner Losh <i...@bsdimp.com> wrote:
> > > On Thu, Sep 26, 2024 at 8:24 AM Alex Bennée <alex.ben...@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 >
