On Mon, Jun 10, 2024 at 09:22:35PM +0300, Manos Pitsidianakis wrote: > What are the issues with not using the compiler, rustc, directly? > ----------------------------------------------------------------- > [whataretheissueswith] Back to [TOC] > > 1. Tooling > Mostly writing up the build-sys tooling to do so. Ideally we'd > compile everything without cargo but rustc directly. > > If we decide we need Rust's `std` library support, we could > investigate whether building it from scratch is a good solution. This > will only build the bits we need in our devices.
Re-building 'std' for QEMU would be a no-go for many distros who will expect QEMU to use the distro provided 'std' package. So at most that would have to be an optional feature. > 2. Rust dependencies > We could go without them completely. I chose deliberately to include > one dependency in my UART implementation, `bilge`[0], because it has > an elegant way of representing typed bitfields for the UART's > registers. > > [0]: Article: https://hecatia-elegua.github.io/blog/no-more-bit-fiddling/ > Crates.io page: https://crates.io/crates/bilge > Repository: https://github.com/hecatia-elegua/bilge > > Should QEMU use third-party dependencies? > ----------------------------------------- > [shouldqemuusethirdparty] Back to [TOC] > > In my personal opinion, if we need a dependency we need a strong > argument for it. A dependency needs a trusted upstream source, a QEMU > maintainer to make sure it us up-to-date in QEMU etc. "strong" is a rather fuzzy term. In C we already have a huge number of build dependencies $ wc -l tests/lcitool/projects/qemu.yml 127 tests/lcitool/projects/qemu.yml we would have many more than that except that we're conservative about adding deps on things because getting new libraries into distros is quite painful, or we lag behind where we would want to be to stick with compat for old distro versions. In terms of Rust dependancies, I'd expect us to have fairly arbitrary dependancies used. If the dep avoids QEMU maintainers having to re-invent the wheel for something there is already a common crate for, then it is a good thing to use it. I'd almost go as far as encouraging use of external crates. Our maintainers should focus tmie on writing code that's delivers compelling features to QEMU, rather than re-creating common APIs that already have good crates. > We already fetch some projects with meson subprojects, so this is not a > new reality. Cargo allows you to define "locked" dependencies which is > the same as only fetching specific commits by SHA. No suspicious > tarballs, and no disappearing dependencies a la left-pad in npm. > > However, I believe it's worth considering vendoring every dependency by > default, if they prove to be few, for the sake of having a local QEMU > git clone buildable without network access. A local git clone is already not buildable without network access, given that you have to install countless extra distro packages ahead of time. I think its reasonable to expect people working from git to have to download rust deps. We should consider whether we want vendoring in the release tarballs though. > Should QEMU provide wrapping Rust APIs over QEMU internals? > ----------------------------------------------------------- > [qemuprovidewrappingrustapis] Back to [TOC] > > My personal opinion is no, with the reasoning being that QEMU internals > are not documented or stable. However I do not see why creating stable > opt-in interfaces is bad. It just needs someone to volunteer to maintain > it and ensure there are no breakages through versions. I expect this will evolve organically with people providing wrappers where appropriate to suit their development neds. > Will QEMU now depend on Rust and thus not build on my XYZ platform? > ------------------------------------------------------------------- > [qemudependonrustnotbuildonxyz] Back to [TOC] > > No, worry about this in some years if this experiment takes off. Rust > has broad platform support and is present in most distro package > managers. In the future we might have gcc support for it as well. Rust isn't going away, so if a platform wants to remain relevant to the modern software world, then people who care about that platform need to ensure Rust works on it. I wouldn't say that QEMU needs to massively worry about this, since all the common platforms are now covered precisely because Rust is becoming so wildly used that a platform cannot ignore 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 :|
