mirror of
https://github.com/facebookexperimental/reverie.git
synced 2025-02-02 09:45:45 +00:00
b1516c3941
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](https://github.com/bitflags/bitflags/pull/373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](https://github.com/bitflags/bitflags/pull/297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00 |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
A safe ptrace interface
This crate provides a safe and Rustic alternative to the infamous ptrace API.
There are many extremely subtle aspects of the raw ptrace API and this crate
helps avoid common pitfalls.
Note that this library is still rather low-level and does not claim to solve all your ptrace problems. You have been warned!
Features
- Ergonomic interface that provides a state machine for ptrace states. This
avoids the infamous
ESRCHerrors that can happen when you use the ptrace API incorrectly. - Provides an interface to read/write guest's memory (see "memory" feature flag).
- Provides an optional and semi-experimental async interface, which can be used
with
tokio(see "notifier" feature).
Usage
Add this to your Cargo.toml file:
safeptrace = "0.1"
Feature Flags
"memory" (off by default)
Provides access to the guest's memory. Memory can only be safely accessed when
the guest is in a stopped state, thus the MemoryAccess trait is only
implemented for the Stopped type.
"notifier" (off by default)
Provides an async interface for ptrace using notifier threads. This is semi-experimental, but testing shows that it has very good performance. It works by spawning a separate thread for each thread being traced, waiting for ptrace events in a loop. Thus, there will be 1 thread per guest thread.
Use with:
safeptrace = { version = "0.1", features = ["async"] }