Tage Johansson
2023-Aug-17 04:13 UTC
[Libguestfs] [libnbd PATCH v7 0/9] Rust Bindings for Libnbd
On 8/16/2023 9:11 PM, Eric Blake wrote:> On Thu, Aug 10, 2023 at 11:24:27AM +0000, Tage Johansson wrote: >> This is the 7th version of the Rust bindings for Libnbd. It is more or >> less identical to the 6th version without the already merged patches. >> >> Best regards, >> Tage >> > I still hope to do more review of both merged patches and this one (in > part, to learn more about Rust myself). But my first observation is > that you currently have several build failures on different platforms. > Here's some CI links summarizing the types of failures I'm seeing, > when I try to turn on --enable-rust as part of our CI coverage:All of these errors are due to the Rustc version is too old. At least rustc 1.70.0 is required. Is it possible to update rust in the CI machines, perhaps with rustup? It is possible to add a minimum version requirement in Cargo.toml, I guess I should do that to make the errors a bit more clear. -- Best regards, Tage> On Debian 12 (similar on Ubuntu): > https://gitlab.com/ebblake/libnbd/-/jobs/4886374776 > line 261: > Get:105 http://deb.debian.org/debian bookworm/main amd64 cargo amd64 0.66.0+ds1-1 [3419 kB] > line 3717..: > Documenting libnbd v0.1.0 (/builds/ebblake/libnbd/rust) > error[E0432]: unresolved imports `std::os::fd::AsRawFd`, `std::os::fd::OwnedFd`, `std::os::fd::RawFd` > --> src/bindings.rs:30:19 > | > 30 | use std::os::fd::{AsRawFd, OwnedFd, RawFd}; > | ^^^^^^^ ^^^^^^^ ^^^^^ no `RawFd` in `os::fd` > | | | > | | no `OwnedFd` in `os::fd` > | no `AsRawFd` in `os::fd` > error[E0412]: cannot find type `c_uint` in this scope > --> src/bindings.rs:120:30 > | > 120 | where F: FnMut(&[u8], u64, c_uint, &mut c_int) -> c_int + Send + Sync > | ^^^^^^ not found in this scope > | > help: consider importing one of these items > | > 24 | use core::ffi::c_uint; > | > 24 | use libc::c_uint; > | > 24 | use std::os::raw::c_uint; > | > ... > Line 5248..: > error[E0603]: module `fd` is private > --> src/bindings.rs:30:14 > | > 30 | use std::os::fd::{AsRawFd, OwnedFd, RawFd}; > | ^^ private module > | > note: the module `fd` is defined here > Line 5270..: > Compiling libnbd v0.1.0 (/builds/ebblake/libnbd/rust) > error[E0432]: unresolved imports `std::os::fd::AsRawFd`, `std::os::fd::OwnedFd`, `std::os::fd::RawFd` > --> src/bindings.rs:30:19 > | > 30 | use std::os::fd::{AsRawFd, OwnedFd, RawFd}; > | ^^^^^^^ ^^^^^^^ ^^^^^ no `RawFd` in `os::fd` > | | | > | | no `OwnedFd` in `os::fd` > | no `AsRawFd` in `os::fd` > Line 7120..: > error[E0599]: no method named `cast_mut` found for raw pointer `*const i8` in the current scope > --> src/bindings.rs:4231:48 > | > 4231 | queries_ffi_c_strs.iter().map(|x| x.as_ptr().cast_mut()).collect(); > | ^^^^^^^^ help: there is an associated function with a similar name: `as_mut` > | > = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref > = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior > > > On to the next one. Centos-stream-8 (and almalinux): > https://gitlab.com/ebblake/libnbd/-/jobs/4886374755 > Line 18: cargo x86_64 1.69.0-1.module_el8+430+506bc849 appstream 4.9 M > https://gitlab.com/ebblake/libnbd/-/jobs/4886374755/artifacts/external_file/rust/test-suite.log > Compiling libnbd v0.1.0 (/builds/ebblake/libnbd/rust) > Compiling tempfile v3.7.1 > error[E0658]: use of unstable library feature 'arc_into_inner' > --> tests/test_245_opt_list_meta_queries.rs:49:16 > | > 49 | let info = Arc::into_inner(info).unwrap().into_inner().unwrap(); > | ^^^^^^^^^^^^^^^ > | > = note: see issue #106894 <https://github.com/rust-lang/rust/issues/106894> for more information > > >
Eric Blake
2023-Aug-17 14:29 UTC
[Libguestfs] [libnbd PATCH v7 0/9] Rust Bindings for Libnbd
On Thu, Aug 17, 2023 at 04:13:36AM +0000, Tage Johansson wrote:> > On 8/16/2023 9:11 PM, Eric Blake wrote: > > On Thu, Aug 10, 2023 at 11:24:27AM +0000, Tage Johansson wrote: > > > This is the 7th version of the Rust bindings for Libnbd. It is more or > > > less identical to the 6th version without the already merged patches. > > > > > > Best regards, > > > Tage > > > > > I still hope to do more review of both merged patches and this one (in > > part, to learn more about Rust myself). But my first observation is > > that you currently have several build failures on different platforms. > > Here's some CI links summarizing the types of failures I'm seeing, > > when I try to turn on --enable-rust as part of our CI coverage: > > > All of these errors are due to the Rustc version is too old. At least rustc > 1.70.0 is required. Is it possible to update rust in the CI machines, > perhaps with rustup?There are several options. A good thing to remember is that both qemu and libvirt have a written policy on supported development platforms. For example: https://www.qemu.org/docs/master/about/build-platforms.html Since libnbd aims to be interoperable with qemu, it is generally advisable that we should strive to compile as much as possible on the same set of platforms as qemu has chosen to be viable for development. The libvirt-ci project provides 'lcitool' which makes it easy to create CI runners for all of these supported systems: https://gitlab.com/libvirt/libvirt-ci which is how I found the problems in our CI - I'm trying to push my patch to bump our CI engine to use the latest definitions, including adding cargo as a build dependency. I'm fine with saying 'to build this aspect, you need to install extra software from your distro', but I'm reluctant to say 'to build this aspect, you need to pull in extra software from a third-party source not already shipped by your distro'. So, as I see it, that leaves us with these options (or some hybrid combination of them): 1. Declare that we really do require 1.70.0 as our minimum version. CI should be tweaked to not even attempt Rust bindings on platforms that don't supply that. This has some suboptions: 1a. tweak ci/manifest.yml to not pull in cargo on affected systems (nbdkit already has examples of avoiding Rust bindings on known-problematic platforms; it would be easy enough to copy that logic over to libnbd) 1b. tweak configure.ac to probe that rustc is new enough to provide all features we depend on. If the Rust environment is too old, refuse to build Rust bindings on that platform, even if cargo is available as a program to call. Note that 1b is better than 1a: both can get the CI green, but only the latter plays nicely to all other developers and not just the CI system. 2. Decide that it is worth trying harder to support Rust bindings back to an older release, based on whatever the CI systems already have. I don't know if Debian 12's 0.66.0 is reasonable, but CentOS 8's 1.69.0 seems fairly close to 1.70.0. But I don't know how easy or hard it would be to get the same functionality using only the older features. Note that the CI system also tries on Debian 11, with an even older cargo 0.47.0, but it passed because configure noted: checking for cargo... cargo checking for rustfmt... no checking if cargo is usable... configure: WARNING: Rust (cargo) is installed but not usable no That's more of a 1b approach, but obviously not quite strong enough to filter out the other old versions on Debian 12.> > It is possible to add a minimum version requirement in Cargo.toml, I guess I > should do that to make the errors a bit more clear.It's okay if older platforms can't build Rust bindings, but anything we can do to make it so that configure detects that gracefully up front (and the rest of the build still succeeds), rather than falling apart later during make when the missing feature turns into a compiler error, is a good thing. And whatever we do, it doesn't hurt if we amend README to call out the minimum Rust version we are willing to support. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org