## Direct, unsafe Rust bindings for Linux's `perf_event_open` system call This crate exports `unsafe` Rust wrappers for Linux system calls for accessing performance monitoring counters and tracing facilities. This includes: - the processor's own performance monitoring registers - kernel counters for things like context switches and page faults - kernel tracepoints, kprobe, and uprobes - processor tracing facilities like Intel's Branch Trace Store (BTS) - hardware breakpoints This crate provides: - a Rust wrapper the Linux `perf_event_open` system call - Rust wrappers for the ioctls you can apply to a file descriptor returned by `perf_event_open` - bindings for `perf_event_open`'s associated header files, automatically generated by `bindgen` All functions are direct, `unsafe` wrappers for the underlying calls. They operate on raw pointers and raw file descriptors. For a type-safe API for basic functionality, see the [perf-event] crate. [perf-event]: https://crates.io/crates/perf-event ### Using perf types on other platforms Even though Windows and Mac don't have the `perf_event_open` system call, the `perf_event_open_sys` crate still builds on those platforms: the type definitions in the `bindings` module can be useful to code that needs to parse perf-related data produced on Linux or Android systems. The syscall and ioctl wrapper functions are not available. ### Updating the System Call Bindings The `bindings` module defines Rust equivalents for the types and constants used by the Linux `perf_event_open` system call and its related ioctls. These are generated automatically from the kernel's C header files, using [bindgen]. Both the interface and the underlying functionality are quite complex, and new features are added at a steady pace. To update the generated bindings: - Run the `regenerate.sh` script, found in the same directory as this `README.md` file. This runs bindgen and splices its output into the `bindings` module's source code, preserving the documentation. - Fix the comments in `src/lib.rs` explaining exactly which version of the kernel headers you generated the bindings from. - Update the crate's major version. Newer versions of the kernel headers may add fields to structs, which is a breaking change. (As explained in the module documentation, properly written user crates should not be affected, but it seems unnecessary to risk `cargo update` breaking builds. When users need new functionality from the bindings, they can update the major version number of this crate they request.) [bindgen]: https://crates.io/crates/bindgen