Message ID | 20241007110342.1298598-1-pbonzini@redhat.com |
---|---|
State | New |
Headers | show |
On Mon, Oct 07, 2024 at 01:03:28PM +0200, Paolo Bonzini wrote: > The following changes since commit b5ab62b3c0050612c7f9b0b4baeb44ebab42775a: > > Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2024-10-04 19:28:37 +0100) > > are available in the Git repository at: > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > for you to fetch changes up to dec4b629fc17fedcd2172066071f99ec8dcc8d8d: > > meson: ensure -mcx16 is passed when detecting ATOMIC128 (2024-10-07 13:01:06 +0200) > > ---------------------------------------------------------------- > * first commit for Rust support > * fix detection of ATOMIC128 on x86_64 > > ---------------------------------------------------------------- > Manos Pitsidianakis (7): > build-sys: Add rust feature option > rust: add bindgen step as a meson dependency > .gitattributes: add Rust diff and merge attributes > meson.build: add HAVE_GLIB_WITH_ALIGNED_ALLOC flag > rust: add crate to expose bindings and interfaces > rust: add utility procedural macro crate > rust: add PL011 device model > > Paolo Bonzini (4): > Require meson version 1.5.0 > configure, meson: detect Rust toolchain > meson: define qemu_isa_flags > meson: ensure -mcx16 is passed when detecting ATOMIC128 > > Pierrick Bouvier (1): > meson: fix machine option for x86_version The current dockerfiles don't include rust, and I see nothing here updating them to add rust, so how is any of this getting test coverage ? Even though this has Rust disabled by default, I would still consider CI enablement to be a pre-requsite for merging even basic Rust support. > > MAINTAINERS | 21 + > configure | 170 +++++- > meson.build | 158 +++++- > rust/wrapper.h | 47 ++ > .gitattributes | 3 + > Kconfig | 1 + > Kconfig.host | 3 + > hw/arm/Kconfig | 30 +- > meson_options.txt | 3 + > python/scripts/vendor.py | 4 +- > python/wheels/meson-1.2.3-py3-none-any.whl | Bin 964928 -> 0 bytes > python/wheels/meson-1.5.0-py3-none-any.whl | Bin 0 -> 959846 bytes > pythondeps.toml | 2 +- > rust/.gitignore | 3 + > rust/Kconfig | 1 + > rust/hw/Kconfig | 2 + > rust/hw/char/Kconfig | 3 + > rust/hw/char/meson.build | 1 + > rust/hw/char/pl011/.gitignore | 2 + > rust/hw/char/pl011/Cargo.lock | 134 +++++ > rust/hw/char/pl011/Cargo.toml | 26 + > rust/hw/char/pl011/README.md | 31 ++ > rust/hw/char/pl011/meson.build | 26 + > rust/hw/char/pl011/src/device.rs | 599 +++++++++++++++++++++ > rust/hw/char/pl011/src/device_class.rs | 70 +++ > rust/hw/char/pl011/src/lib.rs | 586 ++++++++++++++++++++ > rust/hw/char/pl011/src/memory_ops.rs | 59 ++ > rust/hw/meson.build | 1 + > rust/meson.build | 4 + > rust/qemu-api-macros/Cargo.lock | 47 ++ > rust/qemu-api-macros/Cargo.toml | 25 + > rust/qemu-api-macros/README.md | 1 + > rust/qemu-api-macros/meson.build | 25 + > rust/qemu-api-macros/src/lib.rs | 43 ++ > rust/qemu-api/.gitignore | 2 + > rust/qemu-api/Cargo.lock | 7 + > rust/qemu-api/Cargo.toml | 26 + > rust/qemu-api/README.md | 17 + > rust/qemu-api/build.rs | 14 + > rust/qemu-api/meson.build | 24 + > rust/qemu-api/src/definitions.rs | 97 ++++ > rust/qemu-api/src/device_class.rs | 128 +++++ > rust/qemu-api/src/lib.rs | 166 ++++++ > rust/qemu-api/src/tests.rs | 49 ++ > rust/rustfmt.toml | 7 + > scripts/archive-source.sh | 6 +- > scripts/make-release | 5 +- > scripts/meson-buildoptions.sh | 3 + > scripts/rust/rust_root_crate.sh | 13 + > scripts/rust/rustc_args.py | 84 +++ > subprojects/.gitignore | 11 + > subprojects/arbitrary-int-1-rs.wrap | 7 + > subprojects/bilge-0.2-rs.wrap | 7 + > subprojects/bilge-impl-0.2-rs.wrap | 7 + > subprojects/either-1-rs.wrap | 7 + > subprojects/itertools-0.11-rs.wrap | 7 + > .../packagefiles/arbitrary-int-1-rs/meson.build | 19 + > subprojects/packagefiles/bilge-0.2-rs/meson.build | 29 + > .../packagefiles/bilge-impl-0.2-rs/meson.build | 45 ++ > subprojects/packagefiles/either-1-rs/meson.build | 24 + > .../packagefiles/itertools-0.11-rs/meson.build | 30 ++ > .../packagefiles/proc-macro-error-1-rs/meson.build | 40 ++ > .../proc-macro-error-attr-1-rs/meson.build | 32 ++ > .../packagefiles/proc-macro2-1-rs/meson.build | 31 ++ > subprojects/packagefiles/quote-1-rs/meson.build | 29 + > subprojects/packagefiles/syn-2-rs/meson.build | 40 ++ > .../packagefiles/unicode-ident-1-rs/meson.build | 20 + > subprojects/proc-macro-error-1-rs.wrap | 7 + > subprojects/proc-macro-error-attr-1-rs.wrap | 7 + > subprojects/proc-macro2-1-rs.wrap | 7 + > subprojects/quote-1-rs.wrap | 7 + > subprojects/syn-2-rs.wrap | 7 + > subprojects/unicode-ident-1-rs.wrap | 7 + > subprojects/unicode-ident-1-rs/meson.build | 20 + > tests/lcitool/mappings.yml | 2 +- > 75 files changed, 3194 insertions(+), 34 deletions(-) > create mode 100644 rust/wrapper.h > delete mode 100644 python/wheels/meson-1.2.3-py3-none-any.whl > create mode 100644 python/wheels/meson-1.5.0-py3-none-any.whl > create mode 100644 rust/.gitignore > create mode 100644 rust/Kconfig > create mode 100644 rust/hw/Kconfig > create mode 100644 rust/hw/char/Kconfig > create mode 100644 rust/hw/char/meson.build > create mode 100644 rust/hw/char/pl011/.gitignore > create mode 100644 rust/hw/char/pl011/Cargo.lock > create mode 100644 rust/hw/char/pl011/Cargo.toml > create mode 100644 rust/hw/char/pl011/README.md > create mode 100644 rust/hw/char/pl011/meson.build > create mode 100644 rust/hw/char/pl011/src/device.rs > create mode 100644 rust/hw/char/pl011/src/device_class.rs > create mode 100644 rust/hw/char/pl011/src/lib.rs > create mode 100644 rust/hw/char/pl011/src/memory_ops.rs > create mode 100644 rust/hw/meson.build > create mode 100644 rust/meson.build > create mode 100644 rust/qemu-api-macros/Cargo.lock > create mode 100644 rust/qemu-api-macros/Cargo.toml > create mode 100644 rust/qemu-api-macros/README.md > create mode 100644 rust/qemu-api-macros/meson.build > create mode 100644 rust/qemu-api-macros/src/lib.rs > create mode 100644 rust/qemu-api/.gitignore > create mode 100644 rust/qemu-api/Cargo.lock > create mode 100644 rust/qemu-api/Cargo.toml > create mode 100644 rust/qemu-api/README.md > create mode 100644 rust/qemu-api/build.rs > create mode 100644 rust/qemu-api/meson.build > create mode 100644 rust/qemu-api/src/definitions.rs > create mode 100644 rust/qemu-api/src/device_class.rs > create mode 100644 rust/qemu-api/src/lib.rs > create mode 100644 rust/qemu-api/src/tests.rs > create mode 100644 rust/rustfmt.toml > create mode 100755 scripts/rust/rust_root_crate.sh > create mode 100644 scripts/rust/rustc_args.py > create mode 100644 subprojects/arbitrary-int-1-rs.wrap > create mode 100644 subprojects/bilge-0.2-rs.wrap > create mode 100644 subprojects/bilge-impl-0.2-rs.wrap > create mode 100644 subprojects/either-1-rs.wrap > create mode 100644 subprojects/itertools-0.11-rs.wrap > create mode 100644 subprojects/packagefiles/arbitrary-int-1-rs/meson.build > create mode 100644 subprojects/packagefiles/bilge-0.2-rs/meson.build > create mode 100644 subprojects/packagefiles/bilge-impl-0.2-rs/meson.build > create mode 100644 subprojects/packagefiles/either-1-rs/meson.build > create mode 100644 subprojects/packagefiles/itertools-0.11-rs/meson.build > create mode 100644 subprojects/packagefiles/proc-macro-error-1-rs/meson.build > create mode 100644 subprojects/packagefiles/proc-macro-error-attr-1-rs/meson.build > create mode 100644 subprojects/packagefiles/proc-macro2-1-rs/meson.build > create mode 100644 subprojects/packagefiles/quote-1-rs/meson.build > create mode 100644 subprojects/packagefiles/syn-2-rs/meson.build > create mode 100644 subprojects/packagefiles/unicode-ident-1-rs/meson.build > create mode 100644 subprojects/proc-macro-error-1-rs.wrap > create mode 100644 subprojects/proc-macro-error-attr-1-rs.wrap > create mode 100644 subprojects/proc-macro2-1-rs.wrap > create mode 100644 subprojects/quote-1-rs.wrap > create mode 100644 subprojects/syn-2-rs.wrap > create mode 100644 subprojects/unicode-ident-1-rs.wrap > create mode 100644 subprojects/unicode-ident-1-rs/meson.build > -- > 2.46.1 > > With regards, Daniel
On Mon, Oct 7, 2024 at 1:11 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > The current dockerfiles don't include rust, and I see nothing > here updating them to add rust, so how is any of this getting > test coverage ? > > Even though this has Rust disabled by default, I would still > consider CI enablement to be a pre-requsite for merging even > basic Rust support. I agree in general, but there's already a lot of work that can be parallelized and the idea of someone managing Rust-related patches out-of-tree was discarded. So this seemed to be the only way to proceed. Right now only Fedora 39 and 40 (with updates) are able to compile QEMU with Rust enabled. Full CI enablement requires further work to reduce the minimum supported version of the compiler, after which rustc can be added to the libvirt-ci inputs and to the Dockerfiles. Adding a CI job that uses nightly rust (via rustup) is high on my priority list, but first of all I wanted to integrate clippy (because the main point of having a job with nightly rust is to have a heads-up on future clippy warnings). That said, I'm also not sure how one would go adding rustup to a container generated by lcitool (for example should I add a new dockerfile that is _based_ on one that already exists? would that change when Rust/rustc is added to that dockerfile?). I think the best thing to do is to do a presentation to the whole community, maybe next week, explaining the state of the experiment and asking for help. Paolo
On Mon, Oct 07, 2024 at 01:26:52PM +0200, Paolo Bonzini wrote: > On Mon, Oct 7, 2024 at 1:11 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > The current dockerfiles don't include rust, and I see nothing > > here updating them to add rust, so how is any of this getting > > test coverage ? > > > > Even though this has Rust disabled by default, I would still > > consider CI enablement to be a pre-requsite for merging even > > basic Rust support. > > I agree in general, but there's already a lot of work that can be > parallelized and the idea of someone managing Rust-related patches > out-of-tree was discarded. So this seemed to be the only way to > proceed. > > Right now only Fedora 39 and 40 (with updates) are able to compile > QEMU with Rust enabled. Full CI enablement requires further work to > reduce the minimum supported version of the compiler, after which > rustc can be added to the libvirt-ci inputs and to the Dockerfiles. Full CI enablement isn't a requirement until we want to turn on Rust by default. It would be sufficient to have a single job in CI using Fedora 40 that passes '--enable-rust' to demonstrate that this at least working on one platform we expect. > Adding a CI job that uses nightly rust (via rustup) is high on my > priority list, but first of all I wanted to integrate clippy (because > the main point of having a job with nightly rust is to have a heads-up > on future clippy warnings). That said, I'm also not sure how one would > go adding rustup to a container generated by lcitool (for example > should I add a new dockerfile that is _based_ on one that already > exists? would that change when Rust/rustc is added to that > dockerfile?). Having layered dockerfiles is something we try to aviod these days, since each layer turns into another job dependancy in the CI pipeline, expanding the number of stages. If the job is merely to validate nightly clippy do we even need any of the rest of the QEMU build deps present ? Can we not just use a generic pre-existing Rust container and only run clippy in it. If we want to actually build with the cutting edge, then I'd say it is sufficient to have a container based on Fedora rawhide, since that gives a heads up on what's soon to be impacting the next stable distro release, upto 6 months ahead of time - we don't need to be watching& debugging stuff that hasn't even been released by Rust yet IMHO. With regards, Daniel
On Mon, Oct 07, 2024 at 12:47:08PM +0100, Daniel P. Berrangé wrote: > On Mon, Oct 07, 2024 at 01:26:52PM +0200, Paolo Bonzini wrote: > > On Mon, Oct 7, 2024 at 1:11 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > The current dockerfiles don't include rust, and I see nothing > > > here updating them to add rust, so how is any of this getting > > > test coverage ? > > > > > > Even though this has Rust disabled by default, I would still > > > consider CI enablement to be a pre-requsite for merging even > > > basic Rust support. > > > > I agree in general, but there's already a lot of work that can be > > parallelized and the idea of someone managing Rust-related patches > > out-of-tree was discarded. So this seemed to be the only way to > > proceed. > > > > Right now only Fedora 39 and 40 (with updates) are able to compile > > QEMU with Rust enabled. Full CI enablement requires further work to > > reduce the minimum supported version of the compiler, after which > > rustc can be added to the libvirt-ci inputs and to the Dockerfiles. > > Full CI enablement isn't a requirement until we want to turn on > Rust by default. It would be sufficient to have a single job in > CI using Fedora 40 that passes '--enable-rust' to demonstrate that > this at least working on one platform we expect. > > > Adding a CI job that uses nightly rust (via rustup) is high on my > > priority list, but first of all I wanted to integrate clippy (because > > the main point of having a job with nightly rust is to have a heads-up > > on future clippy warnings). That said, I'm also not sure how one would > > go adding rustup to a container generated by lcitool (for example > > should I add a new dockerfile that is _based_ on one that already > > exists? would that change when Rust/rustc is added to that > > dockerfile?). > > Having layered dockerfiles is something we try to aviod these days, > since each layer turns into another job dependancy in the CI > pipeline, expanding the number of stages. I forgot to say that QEMU's 'refresh' script can customize the dockerfiles from lcitool with an arbitrary amount of trailing text - see the 'debian12_extras' for example. > > If the job is merely to validate nightly clippy do we even need > any of the rest of the QEMU build deps present ? Can we not just > use a generic pre-existing Rust container and only run clippy > in it. > > If we want to actually build with the cutting edge, then I'd say > it is sufficient to have a container based on Fedora rawhide, since > that gives a heads up on what's soon to be impacting the next stable > distro release, upto 6 months ahead of time - we don't need to be > watching& debugging stuff that hasn't even been released by Rust > yet IMHO. With regards, Daniel