Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]

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: Type: text/html, Size: 6062 bytes --]