supermachine 0.7.87

Run any OCI/Docker image as a hardware-isolated microVM on macOS HVF (Linux KVM and Windows WHP in progress). Single library API, zero flags for the common case, sub-100 ms cold-restore from snapshot.
Documentation
//! Portable (host-architecture-independent) sentry state types.
//!
//! The rest of [`crate::sentry`] is `cfg(linux + x86_64)` — it is the no-virt
//! process-isolation backend and is full of host syscalls, SUD, and `libc`. But two
//! of its submodules are *pure* Rust (`std` + [`crate::snapshot_frame`], no
//! host-syscall / SUD / `libc`):
//!
//!   * [`state_snap`] — Stage-1 "C0": the versioned, little-endian, bounds-checked
//!     `state.snap` on-disk container plus the shared identity/fd record types.
//!   * [`proctree`] — Stage-1 "C2a": the supervisor-owned guest process tree (vpid
//!     identity + topology) the state snapshot serializes.
//!   * [`netstack`] — the owned loopback byte-stream netstack snapshot codec.
//!
//! They live here, OUTSIDE the Linux gate, so they compile and unit-test on every
//! host (mac/CI), not only the Linux/x86_64 box. That lets the native-execution-VM
//! multi-process warm-restore (#36) and disk-persistence (#30/C4) logic — which is
//! built on these types — be developed with fast local feedback instead of being
//! box-only. The files physically remain under `src/sentry/` (referenced via
//! `#[path]`) and are re-exported from [`crate::sentry`] (`pub use
//! crate::sentry_portable::{netstack, proctree, state_snap}`), so every in-sentry path
//! (`super::state_snap`, `crate::sentry::proctree`, …) is unchanged on Linux.

#[path = "../sentry/state_snap.rs"]
pub mod state_snap;

#[path = "../sentry/proctree.rs"]
pub mod proctree;

#[path = "../sentry/netstack.rs"]
pub mod netstack;