mirrors/crosvm
1
0
Fork 0
mirror of https://chromium.googlesource.com/crosvm/crosvm synced 2025-02-06 02:25:23 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
crosvm/common/cros_asyncv2/Cargo.toml

35 lines
924 B
TOML
Raw Normal View History

cros_asyncv2: Add crate Based on the previous proposal in [1]. * The Executor is now completely platform-agnostic and only relies on the platform to provide a type that implements the `PlatformState` trait. * The crate provides concrete high-level types rather than forcing users to deal with trait objects and async-trait. Currently, only File and Event are supported. Support for timers, sockets, and pipes will be added in subsequent changes. * Each high-level type delegates the implementation to a platform-specific type and exists mainly as a place to hold documentation and tests. * On Unix the io_driver module provides async versions of various IO-related syscalls, which are used by the platform-specific File and Event types to implement the required behavior. * io-uring support can be disabled at compile time. When uring support is enabled, we make a runtime check to decide whether or not to use it. The actual io-uring driver is currently unimplemented and will be added in a subsequent change. One non-trivial downside of this change is that the futures returned by the various async methods are !Send and !Sync, which means that they can only be awaited from the same thread on which they were started. In practice this should be fine since current crosvm (and Chrome OS) code doesn't really make use of sending futures to different threads. This can also be mitigated by using `Executor::spawn_local` and a `oneshot::channel` to isolate the !Send future from the outer async fn (as long as the output of the future is Send). See the crate documentation and the `outer_future_is_send` test in `src/executor.rs` for more details. [1]: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062166 BUG=b:195468578 TEST=unit tests Change-Id: I1aad0885e67a957149e2ec3b4d9df215d9b20d81 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3222223 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2021-07-13 06:14:25 +00:00
[package]
name = "cros_async"
version = "0.2.0"
crosvm: migrate to Rust 2021 edition BUG=none TEST=cq Change-Id: I0059c970879b78bfd40b6ce58b10debcf154b50f Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3508322 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Anton Romanov <romanton@google.com>
2022-03-08 01:16:09 +00:00
edition = "2021"
cros_asyncv2: Add crate Based on the previous proposal in [1]. * The Executor is now completely platform-agnostic and only relies on the platform to provide a type that implements the `PlatformState` trait. * The crate provides concrete high-level types rather than forcing users to deal with trait objects and async-trait. Currently, only File and Event are supported. Support for timers, sockets, and pipes will be added in subsequent changes. * Each high-level type delegates the implementation to a platform-specific type and exists mainly as a place to hold documentation and tests. * On Unix the io_driver module provides async versions of various IO-related syscalls, which are used by the platform-specific File and Event types to implement the required behavior. * io-uring support can be disabled at compile time. When uring support is enabled, we make a runtime check to decide whether or not to use it. The actual io-uring driver is currently unimplemented and will be added in a subsequent change. One non-trivial downside of this change is that the futures returned by the various async methods are !Send and !Sync, which means that they can only be awaited from the same thread on which they were started. In practice this should be fine since current crosvm (and Chrome OS) code doesn't really make use of sending futures to different threads. This can also be mitigated by using `Executor::spawn_local` and a `oneshot::channel` to isolate the !Send future from the outer async fn (as long as the output of the future is Send). See the crate documentation and the `outer_future_is_send` test in `src/executor.rs` for more details. [1]: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062166 BUG=b:195468578 TEST=unit tests Change-Id: I1aad0885e67a957149e2ec3b4d9df215d9b20d81 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3222223 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2021-07-13 06:14:25 +00:00
[features]
uring = ["io-uring"]
[dependencies]
anyhow = "1"
async-task = "4"
data_model = { path = "../data_model" } # provided by ebuild
futures = { version = "0.3", default-features = false, features = ["alloc"] }
intrusive-collections = "0.9"
cros_asyncv2: Enable support for io_uring Benchmark data for vm.Fio.block_stress_rw on my hatch_helios: * without uring: read bw = 92047, write bw = 214790 * with uring: read bw = 114332, write bw = 266586 BUG=b:195468578 TEST=unit tests Change-Id: If02e4a8c7555d6a26f9b204d97bfb9533db55973 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3366173 Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Commit-Queue: Anton Romanov <romanton@google.com>
2021-12-27 14:10:48 +00:00
io-uring = { version = "0.5", optional = true, features = ["unstable"] }
Require memoffset version 0.6 Chrome OS does not currently package memoffset-0.6.5 (only 0.6.4), so building within cros_sdk will fail to find the expected crate. We don't need any API requirements past what is provided by 0.6, so just request that. At the same time, upgrade the cros_asyncv2 memoffset from 0.5 to 0.6 so we don't need two separate versions. (The crosvm ebuild was not requiring a 0.5 version, so this was technically a bug.) BUG=None TEST=cargo build TEST=emerge-hatch crosvm Change-Id: I2b6c778cdbf57977e6fffd73867e0c4818c44a61 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3502625 Auto-Submit: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Vineeth Pillai <vineethrp@google.com> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
2022-03-04 00:33:47 +00:00
memoffset = "0.6"
cros_asyncv2: Add crate Based on the previous proposal in [1]. * The Executor is now completely platform-agnostic and only relies on the platform to provide a type that implements the `PlatformState` trait. * The crate provides concrete high-level types rather than forcing users to deal with trait objects and async-trait. Currently, only File and Event are supported. Support for timers, sockets, and pipes will be added in subsequent changes. * Each high-level type delegates the implementation to a platform-specific type and exists mainly as a place to hold documentation and tests. * On Unix the io_driver module provides async versions of various IO-related syscalls, which are used by the platform-specific File and Event types to implement the required behavior. * io-uring support can be disabled at compile time. When uring support is enabled, we make a runtime check to decide whether or not to use it. The actual io-uring driver is currently unimplemented and will be added in a subsequent change. One non-trivial downside of this change is that the futures returned by the various async methods are !Send and !Sync, which means that they can only be awaited from the same thread on which they were started. In practice this should be fine since current crosvm (and Chrome OS) code doesn't really make use of sending futures to different threads. This can also be mitigated by using `Executor::spawn_local` and a `oneshot::channel` to isolate the !Send future from the outer async fn (as long as the output of the future is Send). See the crate documentation and the `outer_future_is_send` test in `src/executor.rs` for more details. [1]: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062166 BUG=b:195468578 TEST=unit tests Change-Id: I1aad0885e67a957149e2ec3b4d9df215d9b20d81 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3222223 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2021-07-13 06:14:25 +00:00
once_cell = "1.7"
slab = "0.4"
cros_asyncv2: Add support for timers BUG=b:195468578 TEST=unit tests Change-Id: I61f6bca1cfb5b0fe020e2fd5af33aa915c24ec54 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3225746 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2021-10-18 09:05:45 +00:00
smallvec = { version = "1.6.1", default-features = false, features = ["union"] }
cros_asyncv2: Add crate Based on the previous proposal in [1]. * The Executor is now completely platform-agnostic and only relies on the platform to provide a type that implements the `PlatformState` trait. * The crate provides concrete high-level types rather than forcing users to deal with trait objects and async-trait. Currently, only File and Event are supported. Support for timers, sockets, and pipes will be added in subsequent changes. * Each high-level type delegates the implementation to a platform-specific type and exists mainly as a place to hold documentation and tests. * On Unix the io_driver module provides async versions of various IO-related syscalls, which are used by the platform-specific File and Event types to implement the required behavior. * io-uring support can be disabled at compile time. When uring support is enabled, we make a runtime check to decide whether or not to use it. The actual io-uring driver is currently unimplemented and will be added in a subsequent change. One non-trivial downside of this change is that the futures returned by the various async methods are !Send and !Sync, which means that they can only be awaited from the same thread on which they were started. In practice this should be fine since current crosvm (and Chrome OS) code doesn't really make use of sending futures to different threads. This can also be mitigated by using `Executor::spawn_local` and a `oneshot::channel` to isolate the !Send future from the outer async fn (as long as the output of the future is Send). See the crate documentation and the `outer_future_is_send` test in `src/executor.rs` for more details. [1]: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062166 BUG=b:195468578 TEST=unit tests Change-Id: I1aad0885e67a957149e2ec3b4d9df215d9b20d81 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3222223 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
2021-07-13 06:14:25 +00:00
sync = { path = "../sync" } # provided by ebuild
thiserror = "1"
[target.'cfg(unix)'.dependencies]
libc = "0.2"
mio = { version = "0.7", features = ["os-ext"] }
sys_util = { path = "../sys_util" } # provided by ebuild
[dev-dependencies]
futures = { version = "*", features = ["executor"] }
futures-executor = { version = "0.3", features = ["thread-pool"] }
futures-util = "0.3"
tempfile = "3"
[workspace]
Reference in a new issue Copy permalink