On Thu, Oct 03, 2024 at 02:53:08AM -0600, Warner Losh 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? > > > > FeeBSD 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.
I don't think we should over-think the upstream Rust support tiers for QEMU. Rust is one of very few OSS projects that bothers to classify platforms they target to this degree of detail. Most OSS projects will test primarily on Linux, and x86_64 / aarch64, with most everything else done on an adhoc basis, relying on user feedback & patches. eg If I look at what Rust says "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work." I would say that describes the status of most non-Linux / non-x86/arm64 platform combinations, across a very large part of the OSS software ecosystem, including a lot of libraries QEMU depends on. Admittedly, compilers are the area where platform support is taken most seriously, given they are the foundation for everything else above, and the comparison benchmark in this case is the support matrix offered by GCC + CLang combined which is incredibly broad. Above that though, QEMU has a mandatory dep on Glib, and its supported & tested platform set is massively narrower than this. I think it is inevitable that a number of QEMU platforms we can build on will be classified Tier 2 or even 3 by Rust upstream, as just many libraries QEMU depends on today would effectively be "Tier 3" if their upstream actually tried to document such details. What I think is more important than the absolute Tier level, is whether Rust has been ported at all to a given OS + arch combination. This is where tier 3 guides us - an indication that there's been enough interest in Rust for it to have been ported to that target at some point, and thus an expectation (or hope) that it can be kept working, if there are sufficient people downstream who care about that particular Rust target. > 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. In terms of QEMU upstream, we actively test FreeBSD on x86_64 in Gitlab CI, via Cirrus, and to a slightly lesser extent test OpenBSD/NetBSD on x86_64 with our adhoc VM environments. Anything else is delegated to downstream users of QEMU to report bugs to us, though we try not to take code that would obviously break other platforms even if we can't test it ourselves. In Rust, the other BSDs are Tier 3 which is weaker than QEMU aims for x86_64, but on a par with QEMU for non-x86 https://doc.rust-lang.org/rustc/platform-support/netbsd.html https://doc.rust-lang.org/rustc/platform-support/openbsd.html at least they have a designated developer who presumably aims to keep those rust ports working over time. > 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. I don't think being "Tier 2" is a problem - that is still a pretty strong level of support from upstream Rust https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-2-target-policy Beyond that, I don't think any of the upstream Rust tiers are neccessarily a constraint for QEMU, even Tier 3. IMHO what matters more is whether the OS distro in question has managed to successfully package Rust + its stdlib in their distro, to the extent that QEMU is able to build, using the distro provided packages. That is the bar we have for basically every dependency we add to QEMU. Distro support is more important that upstream support. The upstream support is really more of an indication of how hard a life the distro maintainer is going to have keeping it working in their distro, rather than whether QEMU should/should not use it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
