Crate rlx_driver 

RLX driver layer — devices, arenas, buffers, command streams (plan #58).

Borrowed from MAX’s three-layer separation: graph (IR) → engine (compiled artifacts, sessions) → driver (devices, buffers). The Rust spelling sits one crate below rlx-runtime: this crate owns the physical concerns (which device, which buffer slot, which command stream), rlx-runtime owns the logical engine (Session, CompiledGraph, compile cache).

Why split? Three reasons.

1. Backend symmetry. rlx-cpu / rlx-metal don’t currently depend on rlx-runtime; before this split they couldn’t reach the Device enum without a circular dep. The rlx-ir → rlx-driver → backends → rlx-runtime chain is strictly one-way.
2. Testability. A Buffer parity test doesn’t need to pull in the entire compile + execute pipeline.
3. Future swaps. Replacing the engine layer (e.g. for AOT compilation) doesn’t touch the driver.

rlx-runtime re-exports every type here, so existing callers keep working without import changes.

Re-exports

pub use arena::DeviceArena;

pub use buffer::Buffer;

pub use collective::ReduceKind;

pub use collective::all_gather;

pub use collective::all_reduce;

pub use collective::reduce_scatter;

pub use device::Device;

pub use handle::BufferHandle;

pub use stream::CommandStream;

pub use stream::SyncStream;

pub use symmetric::CollectiveError;

pub use symmetric::LocalTransport;

pub use symmetric::Rank;

pub use symmetric::SymmetricBuffer;

pub use symmetric::SymmetricHeap;

pub use symmetric::SymmetricTransport;

Modules

arena

Backend-agnostic arena trait — the contract every backend’s memory plan obeys.

buffer

Explicit host ↔ device buffer abstraction (plan #59).

collective

Collective ops as algorithms over SymmetricTransport (plan #12).

device

Device selection — which backend to use.

handle

Persistent buffer handles — state that survives across forward passes.

stream

Command-stream abstraction.

symmetric

Symmetric-memory primitives for collective ops (plan #49).