These container types are similar to arrays except tuples have
heterogeneous data types and Vec has a dynamic number of elements.
BUG=None
TEST=cargo test -p msg_socket
Change-Id: I2cbbaeb7f13b7700294ac50751530510098ba16d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168588
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The original stated purpose of this trait was to reduce memory
allocations but having the `into_iovec` method return a Vec kind of
defeats that purpose.
Refactor the trait so that it can either convert a T into an iovec or
convert a &[T] into a &[iovec]. Implement the trait for VolatileSlice,
IoSlice, and IoSliceMut and update all the callers.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2210272
Change-Id: I9d0d617a23030d241d50411f4a5a16e7cba4bcee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2208527
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
This implementation makes it impossible to use i32 as ordinary data in a
MsgOnSocket implementation. It is also error prone because i32 is the
default type for integer literals in Rust, and #[derive(MsgOnSocket)] on
structs with an i32 would suddenly be transmitting a RawFd.
This change also replaces the uses of RawFd's MsgOnSocket impl for one
based on File.
TEST=cargo build
BUG=None
Change-Id: I9da392e34e62fe61f773f24d656dbcbf4716f1a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197777
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This caused None values to be transmitted as zero-bytes, which usually
caused not enough buffer space to be allocated for sending.
BUG=None
TEST=cargo test -p msg_socket
Change-Id: If12d2df56689a84054405f2ba15d1c268afad15e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197776
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This adds the ability for getting both supported/emulated cpuids from
the kvm hypervisor. In addition, checking the available capabilities
for kvm is now implemented.
BUG=chromium:1077058
TEST=Added unit tests for each implemented function.
Change-Id: Ide4c2840b7bfa022deae835eb734ea97c1859169
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2177641
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Udam Saini <udam@google.com>
The AsyncReceiver doesn't need to modify the message receiver so let it
take a plain old borrow.
Change-Id: I07e93d2ed12327dd893fec654d2bdd613a848fe6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2167694
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The type of the executor leaked from the cros_async crate. That was fine
until the desire to add a new executor arose. Hide the fd_executor so
that a uring_executor can be substituted on newer kernels.
Change-Id: I8dd309fd47e1b4a6e16da274abbb8431c80474af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2182042
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Fields with a default value can be skipped using the
`#[msg_on_socket(skip)]` attribute.
TEST=cargo test -p msg_socket
BUG=None
Change-Id: I9fea33e641a7da62b7864ba1847e884b32502491
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168587
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
These types are simple wrappers, and so this change just adds trivial
passthroughs.
For data sent over a socket, the data is not Arc-ed or Mutex-ed on the
other end with the same ref count or lock. Sending over the data is more
like a deep copy, rather than a simple ref count increase.
TEST=cargo test -p msg_socket
BUG=None
Change-Id: I519096b0b3b6ab75e79c37addf0d60ce3da4a717
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168586
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Receiving no data can be considered a special case for MsgOnSocket. It
doesn't necessarily indicate EOF because usually messages are sent over
a datagram channel and some fixed sized messages are actually zero
sized. This change handles this by adding a specific result for
receiving no data when at least some was expected. This will also
simplify some error handling that had to unpack the `BadRecvSize`
variant.
TEST=cargo test -p msg_socket
BUG=None
Change-Id: I16feeabc1481de93a2b189989d095434b5b417b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2079178
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
This is to allow the Enum which doesn't have filed type for all its variants
to derive the MsgOnSocket.
BUG=None
TEST=cargo test -p msg_socket
Change-Id: Iab9edda777f42e25af40e4ec0e5870401c17572b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2143572
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
This change is a major shift in how the MsgOnSocket trait works to allow
`self` to be used to determine the result `msg_size()`. This is to
support data structures with `Vec` or other dynamically sized type.
TEST=./build_test
cargo test -p msg_socket
tast run <DUT> crostini.CopyPaste.*
BUG=None
Cq-Depend: chromium:2025907
Change-Id: Ibdb51b377b2a2a77892f6c75e1a9f30b2f8b0240
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2029930
Tested-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Add a member to MsgSocket that effectively returns an async iterator
over messages received on the socket. This is done by setting the socket
as non-blocking and registering with the async infrastructure when the
socket would block.
This feature will be used by devices that wish to handle messages in an
async fn context.
Change-Id: I47c6e83922068820cd19ffd9ef604ed8a16b755e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1997243
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
This change adds the `recv_*_vec` suite of methods for getting an entire
packet into a `Vec` without needing to know the packet size through some
other means.
TEST=cargo test -p sys_util -p msg_socket
BUG=None
Change-Id: Ia4f931ccb91f6de6ee2103387fd95dfad3d3d38b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034025
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
These were pinned at pre-1.0 versions. Update to the stable API to allow
new features to be used in the future.
Cq-Depend: chromium:2026764
Change-Id: Id2d979525e5210436cbb1cfa61e2b05fafb288f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2025907
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The Deref trait is usually only implemented by smart pointers or by
trivial wrappers around the underlying type. MsgSocket does not fit into
either category because it wraps a `UnixSeqPacket` to provide new
functionality. Having it implement can lead to confusing error messages,
especially for people who are new to rust and are not familiar with the
Deref trait and Deref coercion.
For example, calling `sock.send()` on a MsgSocket without first adding
`use msg_socket::MsgSender` leads to the compiler complaining about
mis-matched types for the `send` method. `UnixSeqPacket::send` expects a
`&[u8]` while `MsgSocket::send` expects a `&M`. The compiler also gives
no clues that it is implicitly coercing the socket to a `&UnixSeqPacket`
and using the `send` method from there.
Drop the `Deref` implementation. `MsgSocket` already implements
`AsRef<UniqSeqPacket>` so anything that _needs_ to access the underlying
`UnixSeqPacket` should just use that.
BUG=none
TEST=unit tests
Change-Id: If02ef7173ae21d85d517e808489ed4d6d09ae90b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2002997
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
The `MsgSender` and `MsgReceiver` traits take a type parameter for the
message to be sent / received. However this ends up trickling down to
every user of these traits, who need to add these type parameters
whenever they want to use the trait.
Change the type parameters to associated types instead. The associated
types keep the same trait bounds but now users of the traits don't need
to care about the exact message being sent / received.
BUG=none
TEST=cargo test
Change-Id: I733a21877cbe49b7904040b8cc6c3436d5e3439f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993160
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
uninitialized is deprecated and considered too dangerous to use for any
of the use cases we were using.
BUG=None
TEST=passes smoke_test
Change-Id: I5392cb8ec132f374d9b5590f72eb2cb329a82421
Reviewed-on: https://chromium-review.googlesource.com/1626795
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Extracts BalloonAdjust from VmRequest into BalloonControlCommand.
BUG=None
TEST=cargo test
TEST=cargo test --package msg_socket
TEST=cargo test --package devices
TEST=cargo test --package vm_control
TEST=tast -verbose run ${IP} vm.CrostiniStartEverything
Change-Id: Ia9f5778c37c8fd4fa560df413134d1b441142f64
Reviewed-on: https://chromium-review.googlesource.com/1565298
Commit-Ready: Jakub Staroń <jstaron@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
A few files were missing license blurbs at the top, so update them all
to include them.
BUG=none
TEST=none
Change-Id: Ida101be2e5c255b8cffeb15f5b93f63bfd1b130b
Reviewed-on: https://chromium-review.googlesource.com/1577900
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
As described in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/default-match-bindings.html
which also covers the new mental model that the Rust Book will use for
teaching binding modes and has been found to be more friendly for both
beginners and experienced users.
Before:
match *opt {
Some(ref v) => ...,
None => ...,
}
After:
match opt {
Some(v) => ...,
None => ...,
}
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I3c5800a9be36aaf5d3290ae3bd3116f699cb00b7
Reviewed-on: https://chromium-review.googlesource.com/1566669
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We have:
unsafe trait AlignedNew: Sized + DataInit {...}
unsafe trait DataInit: Copy + Send + Sync {...}
trait Copy: Clone {...}
trait Clone: Sized {...}
Since Sized is already indirectly a supertrait of DataInit, including it
again as a supertrait of AlignedNew has no effect. This CL removes the
redundant Sized bound.
TEST=cargo check
Change-Id: I8ee2a9ee8892c95e6b0dd4bac1b662cd97441984
Reviewed-on: https://chromium-review.googlesource.com/1568077
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Before the new borrow checker in the 2018 edition, we sometimes used to
have to manually insert curly braced blocks to limit the scope of
borrows. These are no longer needed.
Details in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I59f9f98dcc03c8790c53e080a527ad9b68c8d6f3
Reviewed-on: https://chromium-review.googlesource.com/1568075
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In Rust 2018 edition, `extern crate` is no longer required for importing
from other crates. Instead of writing:
extern crate dep;
use dep::Thing;
we write:
use dep::Thing;
In this approach, macros are imported individually from the declaring
crate rather than through #[macro_use]. Before:
#[macro_use]
extern crate sys_util;
After:
use sys_util::{debug, error};
The only place that `extern crate` continues to be required is in
importing the compiler's proc_macro API into a procedural macro crate.
This will hopefully be fixed in a future Rust release.
extern crate proc_macro;
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I0b43768c0d81f2a250b1959fb97ba35cbac56293
Reviewed-on: https://chromium-review.googlesource.com/1565302
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Macros were previously imported through `#[macro_use] extern crate`,
which is basically a glob import of all macros from the crate. As of
2018 edition of Rust, `extern crate` is no longer required and macros
are imported individually like any other item from a dependency. This CL
fills in all the appropriate macro imports that will allow us to remove
our use of `extern crate` in a subsequent CL.
TEST=cargo check --all-features --tests
TEST=kokoro
Change-Id: If2ec08b06b743abf5f62677c6a9927c3d5d90a54
Reviewed-on: https://chromium-review.googlesource.com/1565546
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
The derive(MsgOnSocket) macro used to expand to something like:
const __MSG_ON_SOCKET_IMPL_Typename: () = {
extern crate msg_socket as _msg_socket;
impl _msg_socket::MsgOnSocket for Typename {
...
}
};
This was helpful in 2015 edition code by allowing callers to invoke the
derive without also writing `use msg_socket` at the top of the file to
bring the crate into scope.
In 2018 edition, paths beginning with a crate name do not need to be
otherwise imported, so this derive can simply expand to:
impl msg_socket::MsgOnSocket for Typename {
...
}
TEST=cargo test msg_socket
TEST=cargo test msg_on_socket_derive
Change-Id: I61b672b64404523f601de1d538ebe554985a0905
Reviewed-on: https://chromium-review.googlesource.com/1565545
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This may help reduce cases of conflicts between independent CLs each
appending a dependency at the bottom of the list, of which I hit two
today rebasing some of my open CLs.
TEST=cargo check --all-features
Change-Id: Ief10bb004cc7b44b107dc3841ce36c6b23632aed
Reviewed-on: https://chromium-review.googlesource.com/1557172
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Separated out of CL:1513058 to make it possible to land parts
individually while the affected crate has no other significant CLs
pending. This avoids repeatedly introducing non-textual conflicts with
new code that adds `use` statements.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I6d541d6d51498612c82072c64cb78eefcb2abb8c
Reviewed-on: https://chromium-review.googlesource.com/1519700
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This is an easy step toward adopting 2018 edition eventually, and will
make any future CL that sets `edition = "2018"` this much smaller.
The module system changes in Rust 2018 are described here:
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html
Generated by running:
cargo fix --edition --all
in each workspace, followed by bin/fmt.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I000ab5e69d69aa222c272fae899464bbaf65f6d8
Reviewed-on: https://chromium-review.googlesource.com/1513054
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This is convenient for types that embed Option<...>.
BUG=chromium:831850
TEST=cargo test
Change-Id: I65aa3515f49e4424eff54f17ae18dac8e85b0afa
Reviewed-on: https://chromium-review.googlesource.com/1510812
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
The advantage of seqpacket is that they are connection oriented. A
listener can be created that accepts new connections, useful for the
path based VM control sockets. Previously, the only bidirectional
sockets in crosvm were either stream based or made using socketpair.
This change also whitelists sendmsg and recvmsg for the common device
policy.
TEST=cargo test
BUG=chromium:848187
Change-Id: I83fd46f54bce105a7730632cd013b5e7047db22b
Reviewed-on: https://chromium-review.googlesource.com/1470917
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
I have been running into Debug-printed error messages too often and
needing to look up in the source code each level of nested errors to
find out from the comment on the error variant what the short name of
the variant means in human terms. Worse, many errors (like the one shown
below) already had error strings written but were being printed from the
calling code in the less helpful Debug representation anyway.
Before:
[ERROR:src/main.rs:705] The architecture failed to build the vm: NoVarEmpty
After:
[ERROR:src/main.rs:705] The architecture failed to build the vm: /var/empty doesn't exist, can't jail devices.
TEST=cargo check --all-features
TEST=FEATURES=test emerge-amd64-generic crosvm
Change-Id: I77122c7d6861b2d610de2fff718896918ab21e10
Reviewed-on: https://chromium-review.googlesource.com/1469225
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Instead of using unaligned memory. Allocate aligned memory and copy into it, we
were already doing an clone. There should be no overhead for this new
approach.
BUG=chromium:900962
TEST=build and run
Change-Id: I011d4c93a872d7d285e8898ff332f3ee1ef104a9
Reviewed-on: https://chromium-review.googlesource.com/1344225
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Rustfmt currently does not touch the content of macro invocations. Also
it used to have a bug where if it changed indentation of a block of code
containing a multi-line macro invocation then the macro input would not
get correspondingly indented. That bug was visible across some of the
code here.
For example:
// rustfmt decides to un-indent the surrounding block:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
// poorly formatted resulting code:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
// should have been:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
TEST=cargo check crosvm
TEST=cargo test each of the three proc-macro crates
CQ-DEPEND=CL:1338507
Change-Id: Id2d456a8d85d719fbc0a65624f153f0f9df6f500
Reviewed-on: https://chromium-review.googlesource.com/1338508
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Turns out my cargo-fmt binary was being sourced from ~/.cargo/bin, which
was very out of date. Hopefully less formatting issues come out of my
chroot now.
TEST=cargo fmt --all -- --check
BUG=None
Change-Id: I50592e2781835840dc5d589c681b3438d6de3370
Reviewed-on: https://chromium-review.googlesource.com/1324669
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The types from msg_socket were assumed to be in scope for the custom
derive implementation, which would cause mysterious compiler errors if
the custom derive was invoked in a module without msg_socket types in
scope.
This CL uses fully qualified types in the generated output to avoid
these errors.
This change also uses `extern crate msg_socket` in case the call site
doesn't have it in scope.
BUG=None
TEST=cargo test -p msg_on_socket_derive
Change-Id: Ie6443cd4ffc070d27e71de123090a58f19846472
Reviewed-on: https://chromium-review.googlesource.com/1314208
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
This patch avoids sendmsg/recvmsg if there is no fd.
BUG=chromium:900962
TEST=build local image and test
Change-Id: I3a5fd52232dc7d98dacd78aa0b383a436056ffb7
Reviewed-on: https://chromium-review.googlesource.com/1313656
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
MsgSock wraps UnixDatagram and provides simple macro to define Messages
that could be send through sock easily.
TEST=cargo test
BUG=None
Change-Id: I296fabc41893ad6a3ec42ef82dd29c3b752be8b8
Reviewed-on: https://chromium-review.googlesource.com/1255548
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
