Lib.rs

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.

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.)