Why HarmonyOS’s Microkernel Isn’t Linux Yet Runs Linux Apps

HarmonyOS adopts a microkernel architecture, separating the core kernel functions (process scheduling, memory management, basic IPC) into kernel mode while moving most system services to user mode. This contrasts with Linux’s monolithic kernel where all core services run in kernel space.

Microkernel Benefits and IPC Overhead

By isolating services, the microkernel improves security through reduced attack surface, but increases IPC frequency, making a high‑performance IPC mechanism essential. HarmonyOS optimizes IPC by using synchronous RPC‑like calls that bypass full scheduling and by introducing a trusted isolation class (IC1) for performance‑critical services.

Distributed IPC and Real‑Time Scheduling

HarmonyOS extends IPC to support distributed calls across devices, treating distributed IPC/RPC as first‑class citizens. It also replaces Linux’s Completely Fair Scheduler with a deterministic delay engine that prioritizes user‑interactive and real‑time tasks.

Linux Compatibility Layers

Three key components enable Linux compatibility:

POSIX Compatibility : Implemented via the Kernel Abstraction Layer (KAL) and the lightweight musl libc. POSIX calls (e.g., read(), write(), fork()) are translated by KAL into microkernel service requests.

ABI Shim Layer : Provides a translation layer that intercepts Linux system calls (e.g., int 0x80, syscall) and maps them to HarmonyOS IPC requests using the lsyscall mechanism, handling call reconstruction and state management.

Hardware Driver Framework (HDF) : Offers a unified driver model (OSAL, PAL) and a user‑mode driver container, allowing Linux drivers to run in user space and be managed by the microkernel.

How POSIX Works in HarmonyOS

When an application invokes a POSIX function, musl libc provides the API, and KAL forwards the request to the appropriate microkernel service via IPC. For example, a file open operation becomes an IPC request to the file system service, while thread creation triggers the process/thread management service.

ABI Shim Details

The shim layer resides in kernel space (IC0) and captures Linux syscalls, translating them into one or more IPC messages. It also handles ABI‑related aspects such as signal delivery, memory layout, and ELF loading, supporting both AOSP and OpenHarmony binaries.

HDF and User‑Mode Driver Containers

HDF abstracts hardware drivers, enabling them to run on different kernels (HarmonyOS microkernel, Linux, LiteOS). The user‑mode driver container isolates drivers in a sandbox that mimics parts of the Linux kernel, facilitating driver reuse across platforms.

Implications for HarmonyOS PC and Containers

With robust POSIX and ABI compatibility, HarmonyOS PC could potentially run Linux applications via Wine or similar translation layers. The same mechanisms underpin container runtimes like iSulad, allowing Linux containers to operate on the microkernel.

Conclusion

Although HarmonyOS’s microkernel is not a Linux clone, its combination of high‑performance IPC, distributed capabilities, deterministic scheduling, and the three compatibility layers (POSIX, ABI shim, HDF) makes it feasible to execute Linux binaries and drivers, laying the groundwork for PC support and containerization.