UmkaOS: A Universal, Live-Evolvable Kernel¶

About This Paper¶

UmkaOS is a production-oriented kernel architecture under implementation. This paper describes the system that UmkaOS is designed to become when the architecture is fully implemented. It is not a claim that every facility described here is available in the current build.

Unless stated otherwise:

descriptions of behavior are architectural requirements for the completed system;
performance figures are engineering targets or analytical projections, not benchmark results; and
deployment benefits assume suitable hardware, drivers, and ecosystem integration.

The purpose of making these commitments explicit before implementation is to make the design reviewable and falsifiable. Implementation must eventually demonstrate the specified behavior, compatibility, recovery properties, and performance on real hardware.

Why a New Kernel—and Why Now?¶

The case for a new kernel cannot be that Linux is old or that Rust is fashionable. Linux is a highly capable production kernel with decades of hardware enablement and compatibility knowledge. A replacement is justified only if it can preserve the ecosystem value users depend on while establishing internal properties that would otherwise require pervasive, mutually constraining changes.

Historically, new operating systems have failed to cross two barriers. The ecosystem barrier leaves a technically interesting kernel without applications, drivers, operational tools, or distribution support. The implementation-scale barrier makes reproducing the long tail of production behavior too expensive for a small team. UmkaOS addresses the first through Linux ABI compatibility and the second through specification-driven agentic development coupled to executable verification. Neither removes the engineering work; together they change whether that work can accumulate fast enough to produce a deployable system.

Several changes make 2026 a particularly relevant point to attempt this architecture:

Memory-safe systems programming is mature enough for kernel-scale use. Rust can make safety the default across most of the kernel while isolating the unavoidable unsafe surface at architecture, DMA, MMIO, FFI, and concurrency boundaries.
Compatibility has become executable. LTP, Linux selftests, syzkaller, filesystem suites, packet tests, distribution workloads, and differential tracing turn much of the Linux userspace contract into machine-observable evidence. Agentic development can partition, investigate, implement, and independently verify that evidence in a cumulative loop.
A computer is no longer one CPU plus passive peripherals. GPUs, NPUs, DPUs, storage controllers, connectivity processors, and management controllers contain autonomous execution and memory. Tier M treats that reality as an architectural primitive.
Memory is becoming heterogeneous and composable. Local DRAM, device memory, CXL, compressed memory, persistent media, and remote capacity differ in latency, bandwidth, durability, ownership, and failure domain. The kernel needs one topology-aware model rather than a permanent assumption that all RAM is local and uniform.
Continuous operation now includes cryptographic and hardware change. Long-lived systems must rotate trust anchors, migrate to post-quantum algorithms, replace failing devices, evolve wire formats, and update core policy without treating every transition as a fresh installation.
Isolation and performance can no longer be separate products. Consumer devices, workstations, servers, and embedded systems all need fault containment, but they cannot afford a design that forces every trusted high-rate interaction through a process boundary. Runtime-selected direct and ring transports allow one module model to cover both cases.

These trends do not individually require a new kernel. Linux supports Rust modules, CXL, confidential computing, livepatching, and many forms of isolation. The UmkaOS argument is that the trends interact: a tier-mobile driver affects communication, recovery, DMA, KABI, and evolution; a peer device affects capabilities, topology, memory, service discovery, and failure ownership; a native ABI depends on native internals that were not shaped solely by Linux compatibility. Designing those relationships together is the reason to start from a new architecture.

The proposition is therefore not “replace Linux because Linux cannot evolve.” It is:

Preserve Linux's observable contract as the adoption bridge, while building a native kernel whose internal abstractions are designed from the beginning for safe evolution, heterogeneous hardware, multiple execution domains, and systems that range from personal devices to distributed machines.

1. A Universal Kernel, Not a Kernel for One Market¶

UmkaOS is designed for systems ranging from personal computers and consumer devices to servers, embedded platforms, accelerator-rich machines, and distributed clusters. These are not separate editions of the operating system. They are deployments of one kernel architecture with common mechanisms for resource management, isolation, evolution, hardware discovery, and communication.

The same principles apply everywhere:

hardware topology and capacity are discovered at runtime rather than fixed by compiled limits;
all eight supported architectures are first-class targets: x86-64, AArch64, ARMv7, RISC-V 64, PPC32, PPC64LE, s390x, and LoongArch64;
drivers and services use the same interfaces regardless of their current isolation tier;
local devices, programmable devices, and remote nodes participate in one capability and service model; and
long-running systems can replace policy and subsystem code without discarding persistent state.

Not every deployment enables every subsystem. A laptop may use graphics, audio, power management, process hibernation, and native acceleration for compatibility runtimes while never joining a cluster. An HPC system may use core provisioning, accelerator scheduling, CXL memory, and distributed services. A small embedded system may compile out facilities it does not need. Universality means these configurations remain expressions of one coherent architecture, not that every machine carries every feature at runtime.

2. Linux Compatibility as an Adoption Bridge¶

A new kernel cannot expect broad adoption if existing distributions and applications must first be rewritten for it. UmkaOS therefore targets the observable Linux userspace contract: syscall numbers and arguments, return values and errno, signal behavior, ELF loading, ioctl values, netlink messages, and the externally visible /proc and /sys formats. The goal is for existing Linux userspace—including libc, init systems, containers, desktop environments, and applications—to run without recompilation.

Compatibility is an adoption strategy, not the architectural identity or final limit of UmkaOS. Internally, UmkaOS is not Linux rewritten in Rust. It uses native mechanisms for object capabilities, isolation domains, live evolution, heterogeneous resources, and peer services. Linux determines the observable compatibility contract; it does not dictate the internal mechanism.

As the ecosystem matures, a native UmkaOS ABI and libc port can expose those mechanisms directly. Native applications will be able to use facilities that do not fit naturally into the POSIX/Linux object model, while existing Linux binaries continue to use the compatibility ABI unchanged.

 Existing Linux binaries       Native applications       Ported runtimes
          |                            |                 Wine / Proton /
     Linux-compatible ABI       Native ABI and libc       Node.js / others
          \___________________________|_________________________/
                                      |
                      Native objects and capabilities
                      waits, events, completion queues,
                      domains, memory, and peer services

Candidate native facilities include capability delegation, heterogeneous multi-object waits, peer-service discovery, distributed memory, live-evolution controls, native observability, and unified accelerator management. Compatibility runtimes and language platforms can also be ported to use selected native facilities without moving the semantics they implement into the kernel. The native libc-facing ABI will be stabilized only with sufficient implementation experience; UmkaOS does not need to freeze premature interfaces to preserve the architectural path.

The compatibility challenge¶

Linux ABI compatibility is one of the hardest parts of UmkaOS. A syscall table with matching numbers and argument types is only the visible edge. Real compatibility includes exact return values and errno, partial-success behavior, interruption and restart, signal ordering, races, resource-limit outcomes, namespace interactions, ioctl encodings, netlink attributes, binary structure layouts, filesystem and socket corner cases, and the textual formats consumed from /proc and /sys. Applications also depend on behavior that was never intended as a formal interface but became one through widespread use.

The target is therefore not a percentage guessed from a list of implemented syscalls. UmkaOS must define a testable compatibility surface and demonstrate that existing binaries observe the same contract as they do on current mainline Linux. Some facilities are deliberately excluded, but an interface claimed as compatible must match in its edge cases rather than merely work on the happy path.

Why this is more achievable now¶

Reproducing that long tail would be an unrealistic manual effort if each failure required a developer to discover the relevant subsystem, interpret a large C implementation, reproduce the bug, update the design, write the code, and construct a regression test in isolation. Modern agentic development changes the economics of this work—not by making compatibility automatic, but by making the feedback loop parallel, systematic, and persistent.

The Linux Test Project is particularly well matched to this model. LTP tests provide small, executable statements of observable behavior across syscalls, filesystems, memory management, IPC, namespaces, security, and resource accounting. A failing case can drive a closed loop:

 Run compatibility test against UmkaOS and Linux
                       |
              Capture observable divergence
                       |
       Minimize and classify the failing contract
                       |
      Verify current torvalds/linux master sources
                       |
        Correct the UmkaOS specification first
                       |
       Implement the native UmkaOS mechanism
                       |
        Re-run the test and retain regression

Agents can execute many independent test clusters, trace both kernels, extract the observable contract from current Linux sources, and propose focused specification or implementation changes. Mechanical ledgers preserve which ABI surfaces and edge classes have been exercised, so progress is measured as evidence rather than confidence. Independent verification agents can then challenge both the inferred contract and the proposed fix.

LTP is a foundation, not a completeness oracle. It must be combined with Linux selftests, syzkaller and coverage-guided fuzzing, differential syscall and packet traces, filesystem test suites, container and distribution boot tests, and real applications such as libc, systemd, desktop environments, browsers, databases, language runtimes, Wine, and OCI workloads. Every discovered divergence becomes a permanent regression test and, where necessary, a correction to the canonical specification.

This feedback-driven development model is what makes broad compatibility a credible engineering program today. It does not reduce the standard: external behavior still has to match Linux exactly where compatibility is promised. It reduces the cost of discovering, specifying, implementing, and retaining each part of that contract.

Some Linux facilities are deliberately excluded: Linux .ko modules are replaced by KABI modules; /dev/mem and /dev/kmem conflict with domain isolation; kexec is superseded by live evolution and controlled recovery; and 64-bit kernels do not provide an ia32 compatibility ABI. These are documented compatibility boundaries rather than accidental omissions.

3. Rust as a Safety Default¶

Rust makes memory and thread safety the default for ordinary kernel code. Ownership, borrowing, typed lifetimes, exhaustive enums, and checked interfaces prevent many classes of use-after-free, double-free, invalid aliasing, and data-race defects before code runs.

A production kernel still requires unsafe operations at architecture, assembly, MMIO, DMA, FFI, and low-level concurrency boundaries. UmkaOS does not claim that undefined behavior is impossible. It confines unsafe operations to explicit, documented boundaries and treats each boundary as a proof obligation. Public and private interfaces are documented, unsafe blocks carry safety arguments, and mechanical checks enforce project-wide invariants.

Rust also enables compile-time policies that are impractical in C. Locks carry type-level ordering information, so an invalid nesting order can be rejected during compilation rather than discovered only when runtime lock diagnostics exercise the right path. Address types distinguish physical and virtual addresses, ABI types make byte order and layout explicit, and multi-state conditions use enums rather than overloaded Boolean flags.

Language safety is one layer, not the whole security or reliability model. Hardware DMA, logical races, stale capabilities, malicious modules, firmware failures, and hardware faults require isolation, validation, recovery, and testing in addition to Rust.

4. One Domain Model for Drivers and Services¶

UmkaOS organizes executable components into domains. Communication depends on one question: are the caller and provider in the same domain?

Same domain: a direct generated call, with no isolation transition.
Different domains: a shared-memory request and completion ring between the two domains.

The KABI binding layer selects and caches the transport when a service is bound. Callers use the same generated interface in either case. A module does not hard-code assumptions about where another module runs, and transport can be rebound when a component moves.

Isolation tiers are deployment categories layered on this domain model:

Tier	Deployment	Isolation and intended trust
Tier 0	Kernel domain	Trusted code; direct access; a fatal fault can panic the kernel
Tier 1	Privileged hardware-isolated domain	Containment of accidental faults; not a hostile-code security boundary
Tier 2	Userspace process plus IOMMU	Process isolation for untrusted or strongly contained modules

Tier M complements these three local execution tiers. It describes an autonomous multikernel peer—a programmable device or another machine—rather than code placed in one of the host CPU's privilege domains. A Tier M peer communicates over a hardware or network transport and advertises services through the peer protocol. Its internal software may be a full UmkaOS kernel or a compatible firmware shim. The name is retained because Tier M occupies a distinct place in the deployment model, but it is not a fourth host privilege level.

Drivers are tier-agnostic. The same KABI module can provide direct and ring transports, and an administrator can choose a permitted deployment based on latency, trust, hardware, and fault-containment requirements. Changing tier is a lifecycle operation: the kernel quiesces the component, drains in-flight work, moves or restarts it in the target domain, and atomically rebinds dependent handles.

Fast Tier 1 containment is hardware-dependent. x86-64 can use MPK, newer AArch64 systems can use Permission Overlay Extension, ARMv7 can use DACR domains, and PPC32 can use segment-based isolation. RISC-V 64, PPC64LE in Radix mode, s390x, and LoongArch64 do not currently provide a suitable fast privileged-versus-privileged boundary. On those architectures a requested Tier 1 deployment runs as trusted Tier 0, while Tier 2 remains available for stronger isolation.

Hardware also provides only a finite number of fast domains. Related Tier 1 modules may have to share a domain, especially on AArch64. Sharing preserves isolation from the kernel and other domains but expands the fault blast radius within the group. UmkaOS exposes this degradation rather than describing Tier 1 as uniformly equivalent across hardware.

Crash recovery¶

When a Tier 1 driver faults, the designed recovery path revokes domain and DMA permissions, parks or ejects execution from the failed domain, disconnects its rings, drains or reconciles in-flight I/O, resets the device, reloads the module, and rebinds its services. Tier 2 recovery uses process teardown plus IOMMU revocation.

Recovery time depends on the device reset mechanism, firmware behavior, outstanding I/O, and hardware. The architecture uses bounded deadlines and escalation—function-level reset, bus reset, power-cycle where available, then permanent quarantine—instead of promising that every device can always recover within one fixed interval.

Repeated failure may cause policy to demote a module to a more strongly isolated tier. That is an operational response, not proof that arbitrary or malicious Tier 1 code is safe.

5. KABI: A Stable, Tier-Agnostic Module Interface¶

Linux intentionally does not promise a stable internal driver ABI. UmkaOS instead specifies KABI, a versioned interface between modules and kernel services.

A declarative IDL defines methods, layouts, capability requirements, and transport properties.
The compiler generates compatible Rust and C bindings, direct-call stubs, ring producers, and ring consumers.
Vtables are append-only. Removed operations retain tombstone entries rather than changing the position of later methods.
Version and vtable-size negotiation prevents callers from invoking operations a provider does not implement.
The compatibility policy supports a rolling five-major-release window for each KABI version.
Signed module manifests constrain permitted tiers, capabilities, and transports; trust anchors and revocation lists are rotatable over the system lifetime.

KABI stability is not a promise that all drivers work forever without maintenance. Hardware changes, security revocation, and intentionally unsupported old ABI generations still require action. It is a defined compatibility contract that replaces source-level dependence on changing kernel internals.

6. Live Kernel Evolution¶

UmkaOS is divided by replaceability, independently of its isolation tiers. The Nucleus is a minimal, non-replaceable foundation: bootstrap, a generic evolution orchestrator, a generic invariant-checker framework, and a generic tracked allocator. It contains no subsystem policy and no type-specific runtime algorithms. Everything else is Evolvable, including schedulers, memory policy, capability lookup code, VFS operations, network protocols, and driver logic.

Long-lived state that must survive code and layout changes is allocated from Nucleus-owned tracked storage. Evolvable modules register type descriptors that describe size, alignment, migration, and invariants. The frozen machinery understands descriptors and registries, not the fields of Task, Cred, a socket, or a filesystem object.

Two migration modes cover structural change:

Extension Array: append-only additions preserve the original object and place new fields in versioned extension storage.
Shadow-and-Migrate: reorderings or type changes allocate a new representation and run an explicit migration function under the evolution protocol.

Before a code generation is installed, registered invariant checkers capture and validate the state it would operate on. A stop-the-world window performs the atomic code and descriptor transition, after which CPUs resume using the new generation. Stateless policy changes can use a lighter RCU or atomic-dispatch swap on warm and cold paths.

Evolution is deliberately forward-only. A batch is checked before commitment, but if a failure occurs after some components have advanced, UmkaOS does not restore stale state by pretending the operation never happened. It reports the partial result and recovers forward. Some failures inside the smallest frozen transition window remain fatal design risks and are targets for formal verification and fault injection.

This design supports far more than function patching: it is intended to permit subsystem replacement and data-layout evolution without discarding application state. Whether a given upgrade preserves every connection or operation depends on the subsystem's declared migration contract; the paper does not assume that all arbitrary changes are transparent.

Linux is also advancing beyond traditional function-level livepatching. Its Live Update Orchestrator work preserves selected resources across a specialized kexec transition using versioned serialized state. That is important evidence that full-version updates with retained state are becoming an operational requirement, not a UmkaOS-only concern. The architectural difference is scope: UmkaOS makes tracked allocation, type descriptors, invariant validation, module rebinding, and data evolution common kernel foundations rather than an update protocol added around independently designed subsystem state. The comparison must be evaluated against current Linux as both systems develop; “Linux can only patch functions” is no longer an adequate description of the design space.

7. Tier M and the Peer-Kernel Model¶

A modern computer is already a small distributed system. GPUs schedule thousands of hardware threads and manage private memory. DPUs and SmartNICs run operating systems on general-purpose cores. Storage controllers execute firmware with their own queues, caches, and recovery logic. Management processors remain alive independently of the host CPU. Consumer systems contain similarly autonomous display, camera, audio, connectivity, and security processors.

Conventional host kernels still tend to represent these processors as peripherals behind device-specific host drivers. UmkaOS instead provides Tier M, the multikernel peer model: an autonomous processor can participate as a service provider in the same capability fabric as the host and other nodes.

Tier M is one of the defining reasons for UmkaOS's universal architecture. It applies to a storage controller in a PC, a GPU or NPU in a gaming device, a camera or connectivity processor in a consumer system, an FPGA in an industrial controller, a DPU in a server, and a remote machine in a cluster. The transport and performance differ; the discovery, authority, versioning, and service lifecycle follow one model.

Three ways a service enters the fabric¶

Not every device must run UmkaOS or change its firmware. The capability-service model supports three provider forms:

Device-native provider: the device firmware speaks the peer protocol and advertises its services directly. This is the canonical Tier M path.
Host-proxy provider: a conventional Tier 0, 1, or 2 KABI driver controls legacy hardware and exposes it through the same peer-service interface. Existing devices therefore participate without pretending that they are autonomous peers.
Host-native provider: the host exports one of its own services or resources through the common model.

Consumers bind to a service contract rather than to one of these implementation forms. A block, network, accelerator, serial, USB, TPM, or filesystem service can therefore be backed by device-native firmware, a host proxy, or host-native resources without creating a separate discovery and authorization architecture for each case.

 Conventional hardware                 Autonomous processor
          |                                      |
 Tier 0/1/2 KABI driver                 Tier M implementation
          |                              /                 \
     Host proxy                 Full UmkaOS peer     Firmware shim
          \______________________________|________________/
                                         |
                        Capability advertisement
                                  Service bind
                         Versioned service protocol

Full peer or firmware shim¶

A sufficiently capable device may run a full UmkaOS instance. More constrained or vendor-controlled hardware can retain its existing RTOS or firmware and implement only the peer protocol and the services it provides. The host does not require the two cases to expose different service semantics.

The planned reference firmware shim is on the order of 10,000–18,000 lines of C excluding cryptographic primitives already present in firmware, but actual size depends on transport, services, recovery requirements, and the vendor environment. This is not a promise that every existing device can be converted mechanically. Firmware changes, service implementation, conformance testing, and hardware qualification remain real integration work.

Capability advertisement and binding¶

A peer joins by authenticating, reporting its identity and topology, and advertising service capabilities. A consumer requests a service with required version, performance, locality, durability, and authority constraints. Binding selects an eligible provider and establishes the transport, memory grants, capability scope, and failure policy.

Possession of the resulting handle authorizes operations within the negotiated grant. The peer receives access only to explicitly shared memory and services. Revocation withdraws the grant and invalidates the binding generation rather than relying on every request to repeat a global policy decision.

Isolation and recovery¶

The Tier M boundary is physical or transport-mediated rather than a host privilege-domain switch. PCIe peers are constrained by IOMMU mappings, BAR windows, and granted shared memory; remote peers are constrained by authenticated protocol capabilities and transport protection. The host retains reset or fencing authority where the hardware provides it, such as function- level reset, secondary-bus reset, slot power control, or fabric exclusion.

This does not make peer firmware inherently trustworthy. A compromised peer can corrupt data inside its grants, return malicious protocol messages, or fail while owning state. Consumers validate all peer-controlled input, grants follow least authority, protocols define replay and generation handling, and recovery may quarantine the provider and rebind the service. If a service's only authoritative state was lost with the peer, the loss is reported rather than silently reconstructed from stale data.

One protocol family from device to cluster¶

Tier M uses the same foundational peer protocol for a local programmable device and a remote UmkaOS node. Both participate in one topology graph and capability namespace. PCIe shared memory, RDMA, and other transports carry the same discovery, negotiation, and lifecycle concepts while service-specific protocols define their own data operations.

This does not imply that a local device and remote server have interchangeable performance or failure semantics. Placement uses measured latency, bandwidth, NUMA distance, durability, trust, and health. It does mean that moving an eligible service from a local accelerator to a remote peer—or from a host proxy to device-native firmware—does not require inventing a new authority and discovery system.

The result is a continuum rather than a split between “driver,” “smart device,” and “cluster service”: legacy devices enter through host proxies; programmable devices can become Tier M peers; host resources use the same provider contracts; and remote kernels extend the fabric beyond one machine.

8. Distributed Services and Memory¶

UmkaOS extends kernel services across peer nodes for workloads that benefit from a shared kernel-level fabric. Distribution is optional; it is not imposed on standalone machines.

Distributed shared memory¶

The DSM design uses page-granular MOESI coherence over RDMA, with direct owner-to-requester transfer, subscriber-controlled caching, bounded invalidation, failure recovery, and anti-entropy. Application-visible DSM lets native applications create regions spanning nodes and select strict, causal, or relaxed semantics appropriate to the data.

Remote page-fault latency is a workload and fabric property. The design targets low-single- digit microseconds on suitable RDMA hardware, but that is an evaluation target rather than a universal guarantee. False sharing, node failure, congestion, and coherence traffic can make DSM inappropriate; applications that need explicit message passing retain that choice.

Coordination¶

The distributed lock manager includes leases, recovery, and wait-for-graph deadlock detection. Distributed futex support extends synchronization on DSM-backed memory so a native runtime can use shared-memory primitives across nodes. These mechanisms do not make network partitions disappear: timeout, quorum, fencing, and data-loss semantics remain explicit.

CXL and remote memory¶

CXL-attached memory, compressed memory, swap, and eligible remote memory participate in a unified tier model. Placement policy considers measured latency, bandwidth, topology, access heat, durability, and failure domain rather than treating every non-local byte as equivalent.

9. Scheduling, Power, and Resource Guarantees¶

The general-purpose scheduler is based on EEVDF, with explicit lag and eligibility rather than ad hoc priority boosts. Constant Bandwidth Servers provide admitted CPU bandwidth guarantees, while cgroup limits preserve Linux-visible resource-control behavior.

Core provisioning composes dedicated CPUs, tick suppression, RCU callback offload, interrupt routing, and memory placement into one resource contract for latency-sensitive workloads. Energy-aware placement uses firmware and runtime telemetry across heterogeneous cores. Separate power budgets constrain consumption at task-group, device, and system scope where hardware can measure and enforce them.

The architecture distinguishes guarantees from hints. An admitted CBS reservation is a schedulability contract. Latency preference, energy preference, and application intent are advisory inputs that may not violate correctness, isolation, or admitted guarantees.

10. Memory for Long-Lived, Heterogeneous Systems¶

Physical memory, CPU count, NUMA topology, and device memory are discovered at boot and during hotplug. Page descriptors use virtual metadata mappings so newly attached memory does not require relocating existing metadata.

Allocation state is separated from replaceable policy. Per-CPU magazines and NUMA-local pools serve hot allocation paths without invoking replaceable policy dispatch. Reclaim, placement, compaction, and tier-selection policy run on warm or cold paths and can evolve without changing the allocator's verified state invariants.

A unified tier model covers local DRAM, CXL, compressed memory, swap, and eligible remote memory. It does not assume one fixed ordering: topology and measured performance determine the effective tier relationship on each machine.

Under transient pressure, process memory hibernation provides an alternative to immediate termination. An eligible process can be suspended and its address space moved to backing storage, then resumed through demand paging. This is not always possible—pinned memory, real-time requirements, insufficient backing storage, or unrecoverable pressure may still require the OOM killer—but it adds a recoverable response between reclaim and termination.

11. Storage, Networking, and Ring-Native I/O¶

Cross-domain VFS, block, network, and device operations use fixed-layout shared rings generated from KABI definitions. Same-domain deployments use direct calls through the same logical interfaces. This allows isolation to be selected without maintaining separate driver APIs.

Ring transport naturally accumulates work while a consumer is active. Doorbells and domain transitions can therefore be amortized over batches, and io_uring submissions can flow into the same internal transport model. Batching is not free performance: it trades queueing delay for throughput and is less effective for single-request workloads.

The network receive path keeps NAPI in the trusted kernel execution context while delivering raw packet batches asynchronously to the network domain. GRO and protocol parsing remain in the network service, avoiding a domain switch per packet. NetBuf separates compact metadata from DMA-accessible payload storage, with explicit ownership transfer and recovery.

Storage uses tracked in-flight operations, write-barrier invariants, and crash reconciliation so a failed filesystem or block provider cannot silently strand requests. On-disk compatibility still follows each filesystem's exact format; isolation does not redefine ext4, XFS, Btrfs, or journal semantics.

The performance objective is negative overhead relative to Linux where batching, register- based per-CPU state, lock avoidance, and compact data structures save more cycles than domain isolation costs. The failure threshold is less than 5% overhead on macrobenchmarks, not an allowance to spend. Current figures are analytical and must be replaced or accompanied by reproducible measurements as implementation matures.

12. Security and Authority¶

Object capabilities are the native authority substrate for kernel objects, KABI services, and peer access. Linux credentials, UID/GID rules, and Linux capability bits are implemented as compatibility semantics above that substrate rather than defining every internal access path.

Capabilities support restricted delegation and revocation. Local validation is optimized for the hot path; remote capabilities include explicit expiry, revocation urgency, and network identity. Possession of a bound service handle authorizes calls until its generation or grant is revoked, avoiding repeated policy evaluation on every operation.

The security architecture also specifies:

stackable Linux Security Module hooks and SELinux-compatible behavior;
verified boot and measured execution;
rotatable trust anchors and module-revocation lists;
hybrid classical and post-quantum signatures for boot and modules;
hybrid key establishment for peer communication; and
confidential-computing backends for SEV-SNP, TDX, and ARM CCA.

Post-quantum algorithms are used on cold control paths where their key and signature sizes do not inflate hot request rings. Algorithm agility is essential: a system intended to evolve for decades cannot freeze today's cryptographic choices permanently.

Tier 1 protects against accidental corruption and supports recovery; it is not a sandbox for hostile privileged code. Untrusted drivers belong in Tier 2. Capability checks likewise do not replace memory isolation, IOMMU enforcement, cryptographic authentication, or conventional Linux security semantics.

13. Virtualization, Extensibility, and Native Runtime Integration¶

KVM support integrates hardware virtualization with the UmkaOS memory manager and capability model. Performance-critical architecture backends execute with the privileges required by the hardware, while the userspace VMM remains process-isolated and receives capability-scoped access only to its guest memory and assigned devices. Live migration supports pre-copy and post-copy mechanisms with explicit convergence and failure handling.

eBPF compatibility preserves Linux bytecode and verifier-visible behavior while placing execution in an isolation domain where hardware supports it. The clean-room verifier and JIT remain high-risk implementation areas and will expand incrementally by program type and helper set rather than claiming immediate parity with every moving Linux interface.

UmkaOS also exposes a native heterogeneous wait operation over file descriptors, events, processes, timers, and semaphores. Linux epoll, futex, timerfd, pidfd, and signalfd behavior remains available through the Linux compatibility ABI; native applications need not convert every object into a file descriptor solely to wait on it.

UmkaOS does not implement an NT kernel personality. Wine and Proton remain responsible for NT objects, handles, waits, completion behavior, and the other Windows semantics they emulate. A port can translate those semantics onto native UmkaOS waits, events, semaphores, completion queues, object naming, and related operations where the mapping is sound. Kernel support is a set of general primitives and a small number of translation-friendly quirks, not a second Windows subsystem hidden below Wine.

Avoiding Linux-specific impedance and some wineserver round trips is expected to reduce synchronization latency, but projected operation-level speedups are hypotheses rather than application benchmark results. Performance depends on the quality of the runtime port, how often a workload exercises the accelerated operations, and the behavior of graphics, drivers, and the rest of userspace.

The same principle is broader than Wine. Language runtimes, databases, browsers, game engines, and asynchronous frameworks such as Node.js can continue to use portable Linux interfaces or gain an UmkaOS backend that targets native waits, completion queues, capabilities, and resource controls. Semantics remain in the runtime where they belong; the kernel exposes primitives that fit them without requiring every abstraction to be reduced to a Linux file descriptor or userspace broker.

14. User I/O and Consumer Systems¶

A universal kernel must treat display, input, audio, power, and interactive latency as core system concerns rather than server-side afterthoughts.

UmkaOS preserves Linux-compatible DRM/KMS, evdev, ALSA, TTY, PTY, and console interfaces while allowing their providers to run in any permitted tier. Driver recovery aims to turn recoverable GPU, Wi-Fi, audio, Bluetooth, and input faults into service interruption rather than system reboot. Actual user-visible recovery depends on device reset support and on whether higher layers can reconstruct state.

For laptops, handhelds, and other battery-powered systems, energy-aware scheduling, runtime power management, per-group power budgets, and application intent share one telemetry model. For memory-constrained interactive systems, process hibernation can preserve eligible background applications across transient pressure instead of immediately terminating them.

Android compatibility is not implied merely by implementing Linux syscalls. Android requires Binder semantics, SELinux policy compatibility, DMA-BUF integration, and extensive vendor SoC drivers. The architecture can support such a compatibility effort, but delivering it is a substantial ecosystem and hardware-porting program rather than an automatic consequence of Bionic using Linux system calls.

15. Accelerators and Heterogeneous Compute¶

GPU, NPU, FPGA, and other accelerator providers implement a common capability, memory, and scheduling foundation while retaining device-specific command formats. Cgroups can account for accelerator time and bandwidth alongside CPU and I/O resources. Shared IOMMU mappings permit qualified peer-to-peer DMA paths such as GPU-to-storage or GPU-to-GPU transfer without unnecessary CPU copies.

The framework does not pretend that all accelerators are interchangeable. It standardizes discovery, admission, isolation, memory ownership, completion, accounting, and failure handling; device-specific compilation and execution models remain above that common base.

Small integer-only inference models may advise kernel policy on cold and warm paths. Inference is budgeted, bounded, observable, and replaceable. Administrator-defined limits and conservative fallback algorithms remain authoritative. ML is an optional policy input, not a correctness dependency and not permission to add inference overhead to every syscall, packet, or scheduler tick.

16. Observability and Fault Management¶

The Fault Management Architecture provides a common sense–diagnose–act loop for driver faults, memory errors, device degradation, and peer failure. Events carry stable identities and structured evidence. Recovery policy can reload a driver, retire a page, quarantine a device, fence a peer, or escalate to an administrator.

/ukfs is the native administrative filesystem for structured kernel state, tracing, parameters, health, and evolution controls. Linux-compatible /proc and /sys remain available to existing software. Stable tracepoint identifiers and versioned schemas allow native monitoring tools to survive subsystem evolution.

Autonomous remediation is bounded by policy and evidence. FMA must not convert uncertainty into silent destructive action: diagnoses record confidence, actions are auditable, and irreversible steps require the authority defined by deployment policy.

17. Designing for 50-Year Operation¶

“Fifty-year uptime” is a design constraint, not an empirical claim. No implementation can prove decades of operation in advance. The requirement asks whether architectural choices introduce known reasons that a continuously operated system must eventually reboot, exhaust a resource, lose authority, or become impossible to update.

The design addresses that question through:

live replacement of Evolvable code and migration of long-lived state;
bounded crash recovery and permanent quarantine when recovery cannot succeed;
u64 kernel-internal identifiers and explicit wrap analysis for protocol-mandated narrower counters;
garbage collection or deterministic drain for slab caches, cgroups, virtual address space, capabilities, and other long-lived resources;
rotatable cryptographic algorithms and trust anchors;
proactive memory-page retirement and device-health management; and
data-format and wire-protocol versioning across software generations.

Verifiable software and firmware lineage¶

A system cannot evolve safely for decades if it cannot establish what is running, where it came from, which interfaces it implements, and which authority approved it. UmkaOS therefore connects build provenance, verified boot, module identity, KABI manifests, peer attestation, and evolution history into one lineage model.

Each kernel and module generation must be traceable to its source and specification revision, toolchain, generated interface definitions, build configuration, signer, and verification evidence. Loaded peers report firmware and protocol identities as part of authentication and service advertisement. An evolution event records the old and new generations, migration descriptors, invariant results, signer, and resulting measured state. Operators can ask not only “is this image signed?” but “what contract does it implement, what changed, and which evidence authorized the transition?”

Trust is rotatable rather than permanently rooted in one vendor key. Revocation can exclude a compromised signer, builder, module generation, firmware identity, or peer credential. Rollback policy prevents returning silently to a known-vulnerable generation while still allowing an explicitly authorized recovery image. Long-lived audit records use versioned formats and can be checkpointed outside the machine so local failure cannot erase the system's operational history.

This is a supply-chain and lifecycle property, not a claim that reproducible builds or attestation prove software correct. Provenance establishes identity and process; testing, review, formal methods, and runtime containment establish different parts of assurance.

Counter width alone does not provide longevity, and “live evolution” alone does not ensure safe upgrades. Every resource needs a deallocation path, every generation needs defined wrap behavior, every migration needs invariants, and every persistent format needs a compatibility story. Long-duration stress, repeated recovery, resource-leak testing, and multi-generation upgrade tests are required to validate these properties.

18. Deployment Profiles¶

The completed architecture is intended to support several deployment classes without naming one as primary.

Deployment	Relevant UmkaOS mechanisms	Important dependencies and limits
Personal computers and workstations	Linux application compatibility, graphics/audio/input, driver recovery, process hibernation, native observability	Broad hardware-driver coverage and reliable device reset
Consumer and gaming systems	Interactive scheduling, native primitives for ported compatibility runtimes, low-latency audio/display, power management	Wine/Proton integration and workload-specific validation
Mobile and battery-powered devices	Heterogeneous scheduling, power budgets, runtime PM, hibernation, isolated drivers	Vendor SoC support; Android requires a dedicated compatibility program
Servers and data centers	Live evolution, KABI, FMA, virtualization, resource guarantees, containment	Hardware qualification, syscall completeness, operational tooling
HPC and AI systems	Core provisioning, accelerators, P2P DMA, CXL, optional DSM	Fabric behavior, coherence suitability, accelerator ecosystems
Embedded and industrial systems	Multi-architecture support, capability authority, bounded recovery, long-lived updates	MMU-class hardware, footprint, and available isolation mechanisms
Distributed and composable systems	Peer services, RDMA, DSM, DLM, remote capabilities	Network partitions, trust, vendor protocol adoption, topology latency

UmkaOS targets MMU-equipped systems. It is not intended for microcontrollers with only a few megabytes of memory, and the initial design does not claim formally verified hard real-time behavior at sub-microsecond scale.

19. Performance Commitments and Evaluation¶

Isolation is valuable only if systems can afford to enable it. UmkaOS therefore treats 5% macrobenchmark overhead relative to Linux as a failure threshold, not a performance budget. The objective is to recover isolation costs through savings elsewhere: register-based per-CPU access, compile-time lock discipline without production lockdep overhead, compact metadata, lock-free reads, batched rings, doorbell coalescing, and fewer allocations.

Analytical models currently project low-single-digit overhead for representative x86-64 workloads with fast isolation, with materially different results for cache-cold, single-request, and weak-isolation hardware. These are commitments to test, not measurements to advertise as achieved.

The evaluation program must report at least:

Area	Required evidence
Compatibility	LTP, application suites, container workloads, desktop applications, and ABI differential tests against current Linux
Throughput	Matched Linux/UmkaOS hardware, compiler, firmware, device, and workload configurations
Tail latency	Batched and non-batched workloads, p50 through p99.99, with cache-temperature and interrupt-policy controls
Isolation	Fault injection into driver memory, control flow, DMA, ring ownership, and reset paths
Recovery	Repeated crashes at every lifecycle phase, device-reset escalation, state reconstruction, and leak detection
Evolution	Multi-version layout migration, partial failure, invariant rejection, and sustained operation across upgrades
Architecture coverage	QEMU functional testing plus real-hardware validation for isolation, weak memory ordering, DMA, power, and interrupt behavior
Longevity	Counter exhaustion analysis, repeated create/drain cycles, allocator and VA fragmentation, and long-duration stress

Published results should label each figure as measured, modeled, or targeted and include the hardware, kernel revisions, configuration, workload, and raw reproduction artifacts.

20. Risks and Limits¶

UmkaOS deliberately attempts several difficult things at once. The principal risks are part of the design, not details to hide behind a feature list:

Linux compatibility has a long tail of observable behavior beyond syscall signatures.
Driver availability can block adoption even when the architecture is sound.
eBPF verification, KVM integration, modern filesystems, graphics, and power management are individually major engineering programs.
Fast Tier 1 isolation is unavailable or capacity-limited on several architectures.
Shared Tier 1 domains expand the crash blast radius between co-tenants.
Live state migration can corrupt a running system if descriptors or invariants are wrong.
Distributed coherence is workload-sensitive and must surface partitions and data loss rather than masking them.
PQC, confidential-computing hardware, CXL, and accelerator interfaces continue to evolve.
A universal architecture still needs per-platform drivers, firmware knowledge, and hardware testing.

The mitigation is not to narrow UmkaOS into one market. It is to implement incrementally, make unsupported configurations explicit, preserve architectural invariants across all eight targets, and require evidence before changing a projected property into a product claim.

21. Development and Delivery¶

UmkaOS is developed from a canonical architecture specification. The specification is written at implementation depth: data structures, ownership, algorithms, error paths, wire layouts, cross-subsystem contracts, and multi-architecture behavior are explicit. Mechanical tooling checks references, ABI layouts, pseudocode structure, symbol consistency, and review coverage.

Implementation is performed in a separate kernel repository pinned to a specific specification commit. When implementation exposes an incomplete or contradictory requirement, it files a structured escalation back to the specification. Spec changes undergo ripple analysis before the implementation advances its pin.

That pin is also part of the software-lineage record. Generated KABI definitions, implementation packets, tests, and verification artifacts refer to the same specification generation, making it possible to distinguish an implementation defect from a changed or incomplete contract. Firmware and third-party modules cannot share the identical source pipeline in every case, but their signed manifests carry equivalent identity, interface-version, authority, and provenance claims for admission and later revocation.

AI agents participate in design, implementation, and review, but generated output is not treated as evidence of correctness. Independent review, current primary-source verification, mechanical gates, differential tests, fuzzing, fault injection, and hardware validation remain mandatory. Agentic development changes the scale and explicitness of the specification; it does not relax the production standard.

Linux compatibility is the clearest example of this model's leverage. Test families can be partitioned into reviewable compatibility units; failures can be compared against current Linux in parallel; and each resolved discrepancy feeds the specification, implementation, coverage ledger, and regression suite. The resulting loop is cumulative: later agents inherit executable evidence for earlier compatibility decisions instead of repeatedly rediscovering them from prose or kernel source.

The broad delivery sequence is:

Phase	Outcome
Foundations	Boot, discovery, memory, concurrency, scheduling, capability substrate, and architecture legs
Self-hosting base	Processes, VFS, essential syscalls, shell environment, and initial isolated I/O
Linux system compatibility	systemd-class userspace, containers, networking, storage, io_uring, and expanding eBPF coverage
Production qualification	Hardware drivers, virtualization, fault recovery, compatibility suites, security review, and performance gates
Full platform	Advanced accelerators, peer devices, distributed services, live-evolution breadth, and native-userland growth

The detailed roadmap is allowed to evolve as implementation evidence changes sequencing. The architectural commitments—universal scope, exact observable compatibility where promised, native internal mechanisms, tier-agnostic interfaces, minimal Nucleus, and all-eight-architecture discipline—do not change merely because one subsystem is harder than expected.

Conclusion¶

UmkaOS is designed as a universal native kernel with Linux compatibility as its adoption bridge. It aims to run existing software first, then enable software and runtimes to grow beyond the limits of the compatibility ABI through native backends, a native libc, and a native ABI.

Its central architectural claim is not that Rust alone fixes operating systems, nor that one isolation mechanism fits every processor. The claim is that a coherent combination of safe systems programming, runtime-discovered hardware, domain-selected communication, stable KABI, tracked state evolution, capability authority, and peer services can support systems from personal devices to distributed heterogeneous machines without splitting into unrelated kernels.

That claim remains to be demonstrated by implementation. This paper defines what the finished system is expected to deliver, where hardware and ecosystem dependencies remain, and which measurements will decide whether the design succeeds.