Architecture
AetherXOS rethinks the operating system around two ideas: expose hardware safely via capabilities, and let applications build their own OS as a Library OS.
Monolithic vs. Exokernel
A monolithic kernel hides hardware behind thick abstractions: a single file system, a single scheduler, a single networking stack. Every application pays the cost of that one-size-fits-all design — every syscall, every page fault, every context switch.
An exokernel does the opposite. It only does what a kernel must: track resource ownership and enforce capability boundaries. Everything else — paging, scheduling, filesystems — is moved into application-linked library OS layers. Your app chooses its OS.
- · thick syscall surface
- · kernel does scheduling
- · one network stack
- · hidden hardware
- · thin capability surface
- · user-level scheduling
- · per-app network stack
- · hardware in user-space
Design Pillars
Every resource — pages, NICs, IRQs — is a typed capability. No ambient authority.
POSIX, real-time, unikernel. Linked into your binary. Replaceable per-process.
Drivers run in user space, isolated by capabilities. Crashes don't take down the host.
Memory-safe core, hardware-enforced W^X, signed capability invocations.
Syscall p50 < 90ns. Zero-copy I/O. User-level interrupts on supported NICs.
io_uring-style queues exposed natively. Your app does its own batching.
Interactive Kernel Config Tree
Examine active exokernel parameters or verify driver mappings on-the-fly. Upload your own aetherxos.config tree to visualize dependency trees instantly.