Re: [Libguestfs] [libnbd PATCH v9 5/7] rust: async: Add a couple of integration tests
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...
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