---
title: 'TenonOS: Micro-Library OS for Edge Computing'
url: https://www.emergentmind.com/topics/tenonos
type: topic
---

# TenonOS: Micro-Library OS for Edge Computing

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 [2512.00400].

## 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:

```c
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 [2512.00400].

Source: https://www.emergentmind.com/topics/tenonos