5.7 KiB
5.7 KiB
Glossary
Development reference and historical context. For current operating instructions, use the user manual. Acceptance applies only to the source and artifacts identified in each record.
| Term | Meaning in this repository |
|---|---|
| M0 | Milestone zero: prepare and verify the workstation's cross-build environment. M1 adds the rootfs; M2 adds native init and ARM VM boot. |
| Host / build workstation | The x86_64 Arch Linux computer running the build. |
| Target | The platform being built for: AArch64 Linux on the Pi. |
| x86_64 | The processor architecture of the supported build workstation. |
| AArch64 / aarch64 / arm64 | Names commonly used for 64-bit ARM. Void uses aarch64 for its glibc package target. |
| Cross-compilation | Compiling on one platform to produce code for another. An x86_64 build can produce an ARM executable that does not run directly on its host. |
| Toolchain | Compiler, linker, and related tools used to build software. |
| Sysroot | Target headers and libraries made available to a cross compiler. It is not necessarily a bootable filesystem. |
| ABI | Application binary interface: the machine-level conventions that compiled programs and libraries must agree on. Matching CPU architecture alone is insufficient. |
| libc | The C runtime library. FDS uses glibc for conventional packages and musl inside its static Rust tools. |
| glibc | GNU's C library, used by the main FDS userspace and Void aarch64 packages. |
| musl | An alternative C library used for static FDS-owned programs. It does not replace the system's glibc package set. |
| Static linking | Including needed library code in an executable at build time, so it does not need those shared libraries at startup. It still needs the operating system/kernel. |
| Dynamic linking / loader | Loading shared libraries when a program starts. The ARM glibc loader is /lib/ld-linux-aarch64.so.1. |
| ELF | The executable/library file format inspected by file and readelf. The validator checks architecture and runtime requirements. |
| Rust target triple | A name such as aarch64-unknown-linux-musl specifying the compiler's target platform and library environment. |
| Cargo / Rustup | Cargo builds Rust projects; Rustup installs/selects Rust toolchains and target components. |
| QEMU user mode | Executes a foreign-architecture Linux program on the host. It does not boot or emulate the entire Pi in the M0 example. |
| XBPS | Void's package-management tools and package format, reused by FDS. It is separate from Arch's pacman. |
| xbps-src | Void's source-package build system. It creates packages using recipes called templates. |
| Template | An xbps-src package recipe describing source, dependencies, build actions, and packaging. |
| Submodule / gitlink | A separate Git repository embedded at a path; the parent records the exact upstream commit it expects. |
| Pin | An explicit version, commit, or digest chosen for an input. A source pin alone does not freeze every downloaded dependency. |
| Overlay | An FDS-owned package directory copied into the build tree without modifying tracked upstream packages. |
| masterdir | The generated Void build-container filesystem under vendor/void-packages/masterdir-x86_64/. This is not the target OS root. |
| hostdir | xbps-src's generated cache/output directory under vendor/void-packages/hostdir/. |
| bubblewrap / bwrap | The host tool used to isolate the build environment with Linux namespaces and mounts. No target init system runs inside this M0 container. |
| Manifest | A generated record of package versions or file checksums used to inspect a particular build. |
| Rootfs | The root filesystem used by a running OS, including programs, libraries, and configuration. make rootfs builds its archive. |
| Initramfs | A small early userspace filesystem loaded with the kernel, used before switching to the main root filesystem. |
| PID 1 / init | The first userspace process and the foundation of system startup, supervision, and shutdown. FDS uses native s6. |
| s6 / s6-rc | FDS's process-supervision and service-dependency tools. The service database is compiled while building the image. |
| EROFS | The read-only filesystem format used for SYSTEM and recovery images. |
| tmpfs | A memory-backed filesystem for temporary state. Its contents do not persist through power loss. |
| GPT / PARTNAME | Disk partition metadata and a partition's name. Stage0 discovers SYSTEM using FDS_SYSTEM, rather than a changing /dev/sdX name. |
| NVMe | The internal solid-state storage interface/device. The FDS internal image holds boot, recovery, and machine configuration. |
| SYSTEM / DATA | Cartridge roles: operating-system image and persistent user files, respectively. |
| PROGRAM / ENVIRONMENT | Cartridge roles: application payload and activation/configuration of a known environment. |
| Bay topology | Mapping a physical USB hub/port path to the user-facing BAY 01–12 labels. |
| Hotplug | Inserting or removing a device while the machine is running. Detection does not by itself make removal safe. |
| sysfs / netlink | Linux interfaces used by FDS to inspect devices and receive cartridge events. |
| Profile | A known OS configuration or service selection activated by a cartridge. It is not an arbitrary root script supplied by media. |
| Safe eject | Stopping users of a cartridge, flushing pending writes, unmounting it, then reporting it safe to remove. Use fds eject BAY. |
For how these pieces fit together, read Architecture. For commands that currently work, follow Your first build.