Expand description
Type definitions and utilities for interacting with the Linux API.
Does not depend on the std
crate (i.e. is no_std
) nor libc.
We currently re-export C bindings. This allows normal C code, using libc headers, to work with these kernel types. Normally this can’t be done because the libc and kernel headers contain incompatible definitions.
§Type names
We provide 3 styles of types:
-
snake-cased-types prefixed with
linux_
. These are ABI-compatible with the corresponding kernel types. These types are re-exported in this crate’s generated C header, and are the types used in exported C function APIs. -
snake-cased-types without the
linux_
prefix. These are also ABI-compatible with the corresponding kernel types, and are intended for use in Rust code. They never require or enforce invariants beyond that bytes are initialized, so are safe to transmute from initialized bytes, or from the correspondinglinux_
type if the required bytes are known to be initialized. Seecrate::signal::sigaction
for an example of a type with such invariants.We do not expose these types in C interfaces, since they have the same name as types in the original Linux headers, and often with the same name in C library headers. Exported C APIs should use the
linux_
types in their signatures, and convert internally to the non-prefixed types. In cases where the 2 types are not simply aliased, they usually implementbytemuck::TransparentWrapper
or similar APIs that allow converting values and references in both directions. -
camel-cased types are not necessarily bitwise-compatible with kernel types with similar names. These primarily include
enum
s andbitflags
types. Kernel constants such asO_WRONLY
are typically defined as instants of such types, and are convertible to and from the original integer types.