On Tue, Jun 11, 2024 at 09:18:25AM +0100, Daniel P. Berrangé wrote: > Date: Tue, 11 Jun 2024 09:18:25 +0100 > From: "Daniel P. Berrangé" <berra...@redhat.com> > Subject: Re: [RFC PATCH v1 0/6] Implement ARM PL011 in Rust > > 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.
So should a base lib be introduced to import and wrap all external dependencies? Sort of like osdep.h, so that specific Rust implementations can't import external third-party libraries directly, but only through the base lib. The advantage of this is that we can unify the management of external dependencies and avoid “potentially/overly arbitrary” importing of specific Rust implementations.
