Commit graph

4 commits

Author SHA1 Message Date
Jingkui Wang
7df5a0ef1a usb_util: add sandboxed-libusb feature
make open_fd patch optional. if sandboxed-libusb feature is not selected,
open_fd is not required.
In this case, the code must have access to /dev/bus/usb, and not
external fd is needed.

BUG=chromium:831850
TEST=cargo test

Change-Id: I21fa87dd15d08a03c2fe2b190559abbe6f63dcd5
Reviewed-on: https://chromium-review.googlesource.com/1375019
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>
2018-12-20 13:49:37 -08:00
David Tolnay
088e7f3025 assertions: Use compile-time assertion macro
This depends on the `assertions` crate added in CL:1366819.

`const_assert!(boolean expression)` is a compile-time assertion that
fails to compile if the expression is false.

TEST=`cargo check` each of the modified crates

Change-Id: I559884baf2275b1b506619693cd100a4ffc8adcd
Reviewed-on: https://chromium-review.googlesource.com/1368364
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
2018-12-09 00:48:17 -08:00
David Tolnay
1d4d44a8e2 sync: Mutex type with methods that panic instead of return error
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.

- Crosvm releases are built with panic=abort so poisoning never occurs.
  A panic while a mutex is held (or ever) takes down the entire process.
  Thus we would like for code not to have to consider the possibility of
  poison.

- We could ask developers to always write `.lock().unwrap()` on a
  standard library mutex. However, we would like to stigmatize the use
  of unwrap. It is confusing to permit unwrap but only on mutex lock
  results. During code review it may not always be obvious whether a
  particular unwrap is unwrapping a mutex lock result or a different
  error that should be handled in a more principled way.

Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.

TEST=boot linux

Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-12-05 01:13:41 -08:00
Jingkui Wang
33e08312f2 usb_util: Create libusb wrapper
This wrapper will be part of usb emulation backend.

BUG=chromium:831850
TEST=local build

Change-Id: I084b15201941e4c16c4e3ff9b967e55db09db567
Reviewed-on: https://chromium-review.googlesource.com/1124870
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
2018-12-01 01:08:35 -08:00