On Thu, Oct 3, 2024, 3:53 AM Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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. > Those have been hit or miss for anything not amd64 or aarch64 on FreeBSD. Sometimes they work, sometimes not. But rust support requires special weird kernel options to work at all... so the situation on FreeBSD is more wobbly than you'd otherwise think. We'll see how it evolves, but an 6-8 year lag in upstream support even though community members contrivuted better support at least 4 years ago is a clear red flashing light of caution. Though unlikely, there is a risk that the root cause of this problem causes things to degrade more. And then FreeBSD would fail the supplied packages test. Use this info as you will, but don't just dismiss it out of hand. There is a long history here of unusual friction that rises to the level of concern I won't be brushed off with assurances you don't think it will be a problem. Warner 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 :| > >
