[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v1 0/6] Implement ARM PL011 in Rust
|
From: |
Manos Pitsidianakis |
|
Subject: |
Re: [RFC PATCH v1 0/6] Implement ARM PL011 in Rust |
|
Date: |
Tue, 11 Jun 2024 13:50:41 +0300 |
|
User-agent: |
meli 0.8.6 |
On Tue, 11 Jun 2024 11:18, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
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.
Yes this wasn't meant for the distro case, you're correct.
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
Rust crates.io dependencies tend to "explode" due to the large number of
transitive dependencies and even different versions of the same crates.
Here's an example:
https://landaire.net/on-dependency-usage-in-rust/#what-about-dependency-explosion
This is something to be aware of in general when pulling 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.
That was my reasoning for using the bitfield crate to represent UART
registers.
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.
Sorry, I meant using cargo without network access. This requires setting
up the registry index and caches on your $CARGO_HOME
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.
Agreed.