1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
//! Pre-built runtime assets for [supermachine], packaged as a Rust crate so
//! embedders can `cargo add supermachine-kernel` instead of fetching binaries
//! out of band — with **no network at build time** (the bytes are
//! `include_bytes!`'d into the binary).
//!
//! ## A facade over per-arch sub-crates
//!
//! supermachine runs a **guest** Linux kernel matching the **host** arch (KVM
//! on x86_64 runs an x86_64 guest; HVF on Apple Silicon runs an aarch64
//! guest). Shipping every arch's kernel in one crate would bust the crates.io
//! ~10 MiB cap and make every consumer download kernels they can't use.
//!
//! So this crate is a thin facade. The actual bytes live in per-arch
//! sub-crates, declared as `[target.'cfg(target_arch = ...)']` dependencies:
//!
//! - [`supermachine-kernel-aarch64`] — aarch64 `Image` + init-oci + agent + smpark.ko
//! - [`supermachine-kernel-x86-64`] — x86_64 `bzImage` + busybox + agent
//!
//! Cargo only resolves/downloads the dependency whose `cfg(target_arch)`
//! matches the **compilation target**, so building for x86_64 fetches *only*
//! the x86 sub-crate, and aarch64 fetches *only* the arm one — never the
//! other arch's multi-MiB kernel. This module re-exports the matching
//! sub-crate's public API (`KERNEL_BYTES`, `extract_kernel_to`, …) so callers
//! write arch-agnostic code:
//!
//! ```no_run
//! // Same call on any host; you get that host's guest kernel.
//! supermachine_kernel::extract_kernel_to(
//! std::path::Path::new("/tmp/supermachine/kernel"),
//! ).unwrap();
//! ```
//!
//! ## Arch-specific surface
//!
//! Most of the API is common to both sub-crates: `KERNEL_BYTES` / `KERNEL_LEN`,
//! `SUPERMACHINE_AGENT_BYTES` / `_LEN`, and the `extract_kernel_to{,_with_parents}`
//! / `extract_supermachine_agent_to{,_with_parents}` helpers.
//!
//! Some items exist only on one arch because the backends differ:
//! - **aarch64 only:** `INIT_OCI_BYTES`, `SMPARK_KO_BYTES` (+ their `extract_*`
//! / `_LEN`). The HVF backend uses an `init-oci` PID-1 shim and an
//! `smpark.ko` module for multi-vCPU snapshot capture.
//! - **x86_64 only:** `BUSYBOX_BYTES` (+ `extract_busybox_to*` / `BUSYBOX_LEN`).
//! The KVM backend builds the container rootfs (overlayfs + `switch_root`)
//! directly in the agent initramfs, using a bundled busybox.
//!
//! Code that needs an arch-specific item should gate it with
//! `#[cfg(target_arch = "…")]` to stay portable.
//!
//! [supermachine]: https://crates.io/crates/supermachine
//! [`supermachine-kernel-aarch64`]: https://crates.io/crates/supermachine-kernel-aarch64
//! [`supermachine-kernel-x86-64`]: https://crates.io/crates/supermachine-kernel-x86-64
pub use *;
pub use *;
// The facade only supports the arches supermachine itself runs on. Fail loudly
// rather than silently exporting an empty API on an unsupported target.
compile_error!;