Module registers 

A driver’s REGISTERS: the window onto its device that the kernel granted at spawn.

Why this exists

A driver must name its register window and rely on it, so the window is part of how a Godspeed driver is written, and comes through gs (docs/driver-library.md, step 3). Every driver reached past the standard library for it, with the SDK’s ctx.mmio(); this is the same grant, in the shape the promise covers. AHCI and GENET were the first to take it here, and by the end of that day (2026-10-19) every compiled driver did; scripts/one_way_check.py holds a new one to it.

What it is, and is not

The registers of the device the spawn request named, and nothing else: the kernel resolved the device by its class and mapped exactly its window (CLAUDE.md 12.3, 14.1). registers answers None when no window was granted - a service that is not a driver, or a device that is not there - and a driver says so and parks rather than guessing.

Every access is checked: an offset past the window, or one not aligned to the access’s size, is refused loudly and ends the driver alone (the SDK’s audited layer does the access, CLAUDE.md 18.1). A register’s MEANING - its offset, its bits, the order a device wants them written in - is the device’s, and stays in its driver.

let Some(regs) = gs::driver::registers(&ctx) else {
    ctx.log("mydev: no device was granted - nothing to drive");
    gs::ipc::park(&ctx)
};
let id = regs.read32(0x00);
regs.write32(0x04, 1);

Structs

Registers

The register window the kernel granted this driver. Copy it freely: it is a view of the one window, and every copy reaches the same registers.

Functions

registers

This driver’s register window, or None when the spawn granted none.