TenonOS: Micro-Library OS for Edge Computing

• TenonOS is a library-first operating system framework that modularizes virtualization and OS functions into fine-grained micro-libraries for tailored runtime environments.
• Its dual-component architecture integrates Mortise, a minimal capability-based hypervisor, with Tenon, a deterministic real-time LibOS, achieving a compact footprint and superior scheduling performance.
• The dynamic orchestration engine optimizes resource allocation in heterogeneous, resource-constrained edge environments, supporting mixed-criticality deployments through on-demand library composition.

TenonOS is a self-generating, library-first operating system framework engineered to address the stringent demands of heterogeneous, resource-constrained edge computing environments. Departing from traditional monolithic and layered hypervisor-plus-guest architectures, TenonOS modularizes both virtualization and OS functionality into fine-grained, reusable micro-libraries. It incorporates two principal components: Mortise, a minimal capability-based hypervisor, and Tenon, a deterministic, real-time LibOS. A dynamic orchestration engine composes tailored runtime environments on demand, optimizing for application-specific requirements and hardware configurations. TenonOS achieves a compact memory footprint (361 KiB), superior real-time scheduling (up to 40.28% lower latency than Linux+PREEMPT_RT), and supports dynamic adaption with strong guarantees on resource isolation, maintainability, and scalability (Zhao et al., 29 Nov 2025).

1. Motivations and Design Objectives

Edge computing scenarios present heterogeneity in compute resources (CPUs, GPUs, FPGAs, AI accelerators), dynamic workloads, and tight constraints on memory and power. Conventional OS/hypervisor stacks—such as Xen/KVM plus guest Linux—exhibit redundant virtual memory mappings, double scheduling, high abstraction overhead in network/device emulation, and static resource allocation, resulting in inefficiency and high verification complexity. Furthermore, monolithic kernels with large codebases impede formal verification and adaptation to mixed-criticality or real-time tasks.

The principal TenonOS design goals are:

• Minimal code and resource footprint: Under 400 KiB and approximately 11 K SLoC.
• Extreme modularity: All components are micro-libraries, each included only as required.
• Unified resource management: Elimination of redundancy across virtualization and OS layers.
• Deterministic, priority-based scheduling: Essential for time-critical workloads.
• Dynamic OS instance lifecycle: On-demand creation, suspension, and termination.
• Adaptability to heterogeneous and mixed-criticality deployments.

2. Core Architecture and Component Roles

TenonOS is built on a LibOS-on-LibOS paradigm. All virtualization and OS services are minimal micro-libraries featuring well-defined capability interfaces. The system architecture presents the following layers:

• Mortise hypervisor: A LibOS-based, micro-library hypervisor managing resource isolation, hypercall interfaces, and the full lifecycle of LibOS (Tenon) instances.
• Tenon LibOS: Provides real-time process management, deterministic scheduling, IPC, and drivers as composable micro-libraries.
• Dynamic orchestration engine: Composes customized runtime environments by selecting only necessary micro-libraries per workload, hardware, and QoS objectives.
• Hardware: Supports ARM64 SoCs, GPUs, FPGAs, and accelerators.

Operational layering implements a strictly demand-driven structure: Mortise boots directly on hardware and invokes the orchestration engine, which constructs and links only those Tenon and hypervisor libraries that match current application needs.

3. Mortise Hypervisor and Resource Management

Mortise consists of a minimal core augmented with independent micro-libraries (typically 200–800 SLoC each) for memory, CPU scheduling, device access, hypercall dispatch, and guest instance lifecycle management. Its principal mechanisms include:

• Capability-based isolation: Each library receives only minimal required hardware privileges.
• Two-stage address translation: Recursive page tables and superpages optimize TLB usage.
• Dual allocation modes:
  • Mode 1: Static resource pinning per LibOS instance for temporal predictability.
  • Mode 2: Dynamic, hypercall-driven control—creation, suspension, resumption, and termination—of OS instances.

Hypercall dispatch utilizes a routing table indexed by group/function identifiers. Guest (Tenon) instance lifecycle management is handled by dedicated create, suspend, resume, and terminate routines, reinforcing temporal isolation.

4. Tenon LibOS and Real-Time Scheduling

Tenon implements multi-process management and a hierarchical, priority-driven scheduler operable in both tick and tickless regimes. Task model parameters include priorities ($p_i$), budgets ($C_i$), and deadlines ($D_i$); schedulability is assessed via standard response-time analysis:

$$R_i = C_i + \sum_{j\,:\,p_j > p_i} \Bigl\lceil\frac{R_i}{T_j}\Bigr\rceil\,C_j, \quad \text{schedulable if } R_i \le D_i.$$

The run-queue is dual-sorted by next-deadline and by descending priority. Scheduling selects the thread $\tau = \arg\min_{i\in\mathrm{ready}}\{D_i, -p_i\}$. Context switching is invoked only when the high-priority (ready) thread changes, minimizing overhead. A tickless timer driver further improves efficiency under low interrupt load. Tenon can thus guarantee deterministic, low-latency operation for safety-critical edge applications.

5. Dynamic Orchestration Engine

The orchestration engine interprets high-level objectives (e.g., power, latency, hardware constraints) using an integrated LLM to produce structured constraints. It operates on a library-relation graph $G = (V, E)$, where each library node $v \in V$ is assigned a semantic relevance score $s_v$. It seeks a subset $L \subseteq V$ that maximizes utility $U(L)$ subject to total resource budgets and dependency requirements, solving:

$$\max_{L\subseteq V}\; U(L)\quad \text{s.t.} \;\sum_{v\in L}r(v)\le R_{\max},\: \forall (u\to v)\in E,\; u\in L\Rightarrow v\in L.$$

A greedy selection algorithm iteratively adds libraries to $L$ in descending order of $s_v/$cost, terminating on budget exhaustion or dependency violation. This ensures only relevant micro-libraries are loaded, optimizing for both system goals and constraints.

6. Implementation and Evaluation

TenonOS totals 11,348 SLoC, consuming 361,229 bytes in memory (including .text, .data, and .bss sections). A compositional breakdown is provided:

Component	.text	.data	.bss	total
arch/arm64	24,648	3,136	8,852	36,636
platform	912	1,484	16	2,412
drivers	4,644	992	206	5,842
lib	159,732	24,580	131,959	316,271
Total	189,956	30,192	141,033	361,229

Key data structures for dispatch and orchestration include:

struct hyptbl_entry { uint16_t group_id; uint16_t fn_id; void (*handler)(uintptr_t); }; struct lib_node { char name[16]; uint32_t cost; uint32_t score; uint32_t deps_mask; };

Performance testing indicates:

• Scheduling latency: TenonOS exhibits 40.28% reduction compared to Linux+PREEMPT_RT baseline.
• Footprint: Occupies 361 KiB vs. NOVA (1 MiB) and Bao (512 KiB).
• Boot times: TenonOS bare completes in 0.03456 s; solo in Mortise 0.03518 s; co-located with Linux 2.0468 s; Linux bare is 1.8820 s.
• Scalability: Scheduling cost grows linearly up to 100 threads.
• Dynamic adaptation: Tenon instances can be reconfigured in under 1 ms via hypercalls.

7. Security, Maintainability, and Portability Considerations

Security is enhanced by confining all privileges to minimally-scoped micro-libraries. Capability-based binding, along with a minimal trusted computing base (11 K SLoC), promotes tractability for formal verification and audit. The on-demand selection of libraries by the orchestration engine minimizes attack surface and attack persistence. The physically small footprint, architecture-agnostic micro-libraries, and hardware-aware composition render TenonOS readily portable across a range of SoCs, from low-power IoT devices to multi-core edge servers. This enables deployment scenarios previously impeded by the rigidity, resource consumption, and abstraction duplication found in monolithic systems (Zhao et al., 29 Nov 2025).