On Wed, Aug 30, 2023 at 08:42:00AM -0500, Eric Blake wrote: > On Tue, Aug 29, 2023 at 05:17:19PM -0500, Eric Blake wrote: > > On Sat, Aug 26, 2023 at 11:29:58AM +0000, Tage Johansson wrote: > > > Add a couple of integration tests as rust/tests/test_async_*.rs. They > > > are very similar to the tests for the synchronous API. > > > --- > > > > > rust/tests/test_async_460_block_status.rs | 98 ++++++++++++ > > > rust/tests/test_async_620_stats.rs | 69 ++++++++ > > > > Our series crossed paths. My commit 5aec7d3b add > > test_465_block_status_64.rs, but this commit of yours (at 0ed92592) > > did not add a counterpart async test, because you started your series > > before I added the 64-bit block status API. Since I heavily > > copy/pasted the synchronous 460 into 465, I'll probably end up doing > > the same for the async version, unless you beat me to it. > > I've done that in commit ac633f84. It missed Rich's cut of release > 1.17.4, and CI is now picking up a different set of failures, but it's > progress. > > x86_64-freebsd-current, aarch64-macos-13: > Compiling epoll v4.3.3 > error[E0425]: cannot find value `EPOLL_CTL_ADD` in crate `libc` > --> > /.cargo/registry/src/index.crates.io-6f17d22bba15001f/epoll-4.3.3/src/lib.rs:19:27 > | > 19 | EPOLL_CTL_ADD = libc::EPOLL_CTL_ADD, > | ^^^^^^^^^^^^^ not found in `libc` > | > help: consider importing this unit variant > | > 11 + use ControlOptions::EPOLL_CTL_ADD;
Note that epoll() is a Linux-specific syscall, with no direct BSD counterpart, explaining the failures on FreeBSD and MacOS with its BSD heritage. https://www.reddit.com/r/rust/comments/65kflg/does_rust_have_native_epoll_support/ mentions how epoll is Linux-specific, and has comments about tokio trying to build on top of mio in order to be platform-independent (mio uses epoll on Linux where it is available, but does not require epoll on other platforms). Right now, I see rust/Cargo.tml is explicitly requiring epoll, which means it can only be built on Linux. Is there a way to drop the explicit dependency on epoll, where we instead configure epoll to use whatever it prefers (deferring to mio and eventually epoll on Linux, but to other code on BSD)? Or at a bare minimum, can we make it so that compiling the Rust async handler be limited to Linux-only, while building the synchronous code still works on BSD? [If it doesn't show by the content of my questions, I'm still quite new to Rust, and trying to figure out how crate dependencies work in cross-platform environments] -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
