📦 Modules

Xila is organized as composable modules with explicit contracts and concrete implementations. Most core modules expose a singleton manager (OnceLock + lock-protected state), then publish a typed API consumed by other modules and executables.

This section is an architecture map, grouped by system role.

Recommended reading order

1. 🗃️ Virtual file system
2. 🏁 Task
3. 🌐 Network
4. 🔗 ABI
5. 🔗 Bindings (runtime integration path)
6. Remaining modules and integrations: 🧠 Memory, 👥 Users, 🕓 Time, 📝 Log, 🖼️ Graphics, 🖥️ Virtual machine

Foundation modules

• 🧠 Memory: Allocation contract (ManagerTrait), global allocator bridge, capability flags, and cache/page helpers.
• 🏁 Task: Global task registry, executor/spawner integration, metadata inheritance, and signal delivery.
• 👥 Users: In-memory user/group database and identifier/membership resolution.
• 🕓 Time: Global time source abstraction over a direct character device.
• 📝 Log: Global logging bridge (LoggerTrait) on top of log ecosystem integration.

Runtime modules

• 🗃️ Virtual file system: Path namespace, mount dispatch (file systems/devices/pipes), ownership/permission checks.
• 🌐 Network: smoltcp interface stacks, runner tasks, control-device surface under /devices/network/*.
• 🖼️ Graphics: LVGL runtime management, display/input plumbing, window/event services.

Interop and runtime-integration pages

• 🔗 ABI: C ABI surface split across declarations, symbol definitions, and per-task ABI context.
• 🔗 Bindings: Module-adjacent runtime integration implemented in executable/WASM host paths for host-call dispatch and guest/host pointer translation.
• 🖥️ Virtual machine: Module-adjacent runtime integration implemented in executable/WASM host paths for WAMR execution, instantiation, and host callback wiring.

Cross-module wiring (high level)