the x86_64 crate gives Rust kernel code the instructions it needs

Instructions, registers and structures, and nothing else

x86_64 is a library to program x86_64 hardware, and the scope statement in the documentation is precise: support for x86_64 specific instructions such as a TLB flush, registers such as control registers, and structures such as page tables.

Those three categories are the whole product, and they are exactly the things a user space application never needs. A TLB flush, a read of a control register such as CR3, a page table entry you can construct and write, these are the operations an operating system kernel performs constantly and a normal program never touches.

So the audience is narrow and specific: people writing kernels, bootloaders, hypervisors or firmware in Rust, where the standard library is unavailable or inappropriate. The crate is tagged with the no_std category in its manifest, and that keyword is the clearest signal of the intended environment.

The design goal is to remove the most tedious part of that work. Page table structures in particular are painful to define by hand, because the bit layouts are error prone and the compiler will not catch a misplaced flag. Handing that to a typed, bit-flag based representation is the main value on offer.

The manifest names six authors, and the crate description in the package metadata matches the README wording exactly, which suggests the documentation and the manifest are kept in step rather than drifting apart.

Feature flags decide whether stable Rust is enough

The default build is not the build most stable-Rust users can use, and this is the single most important thing to understand before adopting the crate.

The default feature list in the manifest is instructions, and the nightly feature is enabled by default as well, according to the feature flag documentation. The nightly flag enables features only available on nightly Rust, while the instructions flag turns on the x86_64 specific instructions and dependent features, and is only available for x86_64 targets.

The minimum supported Rust version is stated as a conditional. If no nightly features are enabled, Rust 1.98.0 is required, and the documentation gives the two ways to get there:

--no-default-features --features instructions

--no-default-features

If the nightly feature or any of its sub-features is enabled, which is the default, a recent nightly is required.

That is a real constraint for kernel projects, because many pin a specific toolchain through a rust-toolchain.toml file, and this repository has one at its root. A project that wants stable Rust has to opt out explicitly, and the instructions feature also carries the caveat that it only works on x86_64 targets, so the crate cannot be a blanket dependency across a multi-architecture workspace.

The full feature list in the manifest includes memory_encryption, abi_x86_interrupt, step_trait and doc_cfg, with nightly expanding into step_trait and abi_x86_interrupt. The memory_encryption feature in particular suggests a focus on the machine check and encrypted memory work that modern kernels need.

A component library next to raw-cpuid, uefi and volatile

The project states its limits before you hit them. This crate does not attempt to handle every facet of OS development, and the documentation then names the other crates in the space, which is the most useful paragraph in the README for anyone assembling a kernel.

raw-cpuid provides safe wrappers around the cpuid instruction, and unlike the raw binary values the cpuid instruction returns, it provides parsed versions of the CPUID data. It supports AMD and Intel specific values, and it works on x86 and x86_64 systems in both user and kernel mode. The difference in approach is that x86_64 gives you the privileged hardware, while raw-cpuid gives you the feature discovery that tells you what the CPU can do.

uefi provides abstractions for UEFI, the successor to BIOS, with UEFI tables, functions and types, and it is useful both for writing UEFI applications and for calling UEFI functions from an OS. It works on a variety of modern platforms, not just x86_64. That is the alternative path for the boot phase, where x86_64 has nothing to say because UEFI is a firmware interface rather than a processor mode.

volatile provides an interface to read_volatile and write_volatile, which makes it easier to program MMIO interfaces and devices, and it works on any Rust target. The dependency list in the x86_64 manifest already includes volatile, at version 0.4.4, alongside bit_field, bitflags and const_fn, so the memory-mapped I/O piece is partially covered by the crate itself and the standalone crate is the broader tool.

The pattern is clear. Take x86_64 for privileged instructions and structures, raw-cpuid for processor detection, uefi for firmware and volatile for device access.

Adding the dependency and choosing the feature set

The manifest is the specification, and it is short enough to read in full. The package metadata that matters for a consumer:

[package]
description = "Support for x86_64 specific instructions, registers, and structures."
documentation = "https://docs.rs/x86_64"
keywords = ["amd64", "x86", "x86_64", "no_std"]
categories = ["no-std"]
license = "MIT/Apache-2.0"
name = "x86_64"
version = "0.16.0-rc.0"
edition = "2024"
rust-version = "1.98"

The feature table it exposes:

[features]
default = ["instructions"]
instructions = []
memory_encryption = []
nightly = ["step_trait", "abi_x86_interrupt"]
abi_x86_interrupt = []
step_trait = []
doc_cfg = []

Two things in there deserve attention. The first is that the default set contains only instructions, while the documentation says the nightly feature is enabled by default, so the effective default build in practice is a nightly build. The second is that the crate uses the 2024 edition and requires Rust 1.98, which is a recent toolchain floor, and it is why the MSRV note in the README talks about how to turn features off rather than how to upgrade.

The dependencies are equally small. bit_field at 0.10.1 handles the bit layout work, bitflags at 2.3.2 provides the flag types, volatile at 0.4.4 provides the memory-mapped access primitives, and const_fn at 0.4.11 allows more work in const contexts.

The documentation lives on docs.rs, and the manifest asks the docs build to use all features, so the published documentation shows the nightly-only API as well.

A release candidate with releases switched off in the metadata

The repository has no GitHub releases, and the manifest version is 0.16.0-rc.0, a release candidate. Those two facts are consistent with how the project publishes, because the release metadata in the manifest is explicit about it.

The package metadata for release sets dev-version to false, sets publish to false and sets tag to false, and configures a pre-release commit message of Bump version to {{version}}. It also sets up a pre-release replacement rule that rewrites the Unreleased heading in Changelog.md into a dated version heading, exactly once.

So the release flow is: a commit bumps the version, the changelog gets its heading rewritten, and the publish and tag steps are performed by something other than the manifest, since the manifest disables them. For a consumer, the practical consequence is that the crate version and the repository tags are not necessarily the same thing, so pinning to a crates.io version and pinning to a git revision can give you different code.

That matters more than usual here, because the crate sits in the dependency graph of a kernel, where a change in a page table structure or a control register wrapper is not a routine patch. The repository does carry a Changelog.md, and the SECURITY.md file at the root suggests vulnerability reports have a defined path, which is a sensible thing to check before you build an OS on top of it.

The last push was on 2026-10-11 and the repository is not archived, so work is still landing.

Licence, layout and what to read first

The licence is dual, MIT and Apache-2.0, declared in the manifest as MIT/Apache-2.0 with both texts committed as LICENSE-APACHE and LICENSE-MIT at the repository root. That is the permissive pairing that lets a kernel project adopt it without relicensing questions, and it is the same choice the neighbouring crates in the ecosystem make.

The repository layout is small and says something about the project. There is src/ for the library, testing/ for the test setup, scripts/ for helper tooling, a Cargo.toml, a Changelog.md, an AUTHORS file, a rust-toolchain.toml that pins the toolchain for contributors, a typos.toml that configures a spell checker, and .github/ for the workflows, including the build workflow the badge points at.

The testing directory is worth a look before you rely on the crate. Kernel libraries are hard to test on a normal host, and a crate that carries its own test infrastructure is telling you something about how its maintainers verify behaviour. The docs.rs metadata builds the documentation with all features, so the published API reference includes the nightly-only surface, which is worth bookmarking when you are working with abi_x86_interrupt or step_trait.

For a first contact, the sensible order is the feature flag documentation, then the manifest, then the docs.rs pages for the specific structures you need, such as the page table types. The README itself is short by design, since it points at other crates rather than trying to be a manual.

Editorial conclusion

Adopt x86_64 when you are writing Rust for an operating system kernel or a bare metal target and want typed access to control registers, page tables and privileged instructions without hand rolling the layouts. Do not reach for it in user space applications, where the standard library already covers what you need. Verify first whether your build can tolerate the default nightly feature, and if not, build with --no-default-features --features instructions against Rust 1.98.0, since the manifest version is 0.16.0-rc.0 and the release metadata sets publish and tag to false.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rust-osdev/x86_64 on GitHub