QSOE: A QNX-inspired Dual-Kernel OS for Microkernel Architectures
QSOE is an open-source project introducing a QNX-inspired operating system with a unique dual-kernel architecture. It provides a shared userspace abstraction over two distinct microkernels (a custom 'Skimmer' kernel and seL4), demonstrating a flexible approach to OS design and microkernel compatibility. This design allows for experimentation with different kernel implementations while maintaining a consistent user experience.
Read original on Hacker NewsIntroduction to QSOE's Dual-Kernel Philosophy
QSOE (QNX-inspired OS Environment) presents an intriguing approach to operating system design by employing a dual-kernel architecture. This means the project maintains two distinct kernel implementations beneath a shared userspace. The primary motivation is to explore and provide a QNX-compatible environment while abstracting away the underlying microkernel differences. This architectural decision highlights the flexibility and modularity inherent in microkernel designs, allowing for innovation at the kernel level without necessitating a complete rewrite of user-facing components.
Architectural Components
- QSOE/N (v0.17): Features the custom-built 'Skimmer' kernel, designed from the ground up for the QSOE project.
- QSOE/L (v0.14): Integrates with the well-regarded seL4 microkernel, known for its formal verification and security properties.
- mr-bml v0.5.1: A GRUB-derived boot loader supporting various kernel styles, including Multiboot 3 and RISC-V Linux-style kernels.
- quser v0.5: Provides the core userspace environment, including an mksh-based shell (qsh).
- libc v0.6: The standard C library, which, like quser and qsh, is largely shared between the two kernel variants.
Shared Userspace & Kernel Abstraction
A key design principle of QSOE is the shared userspace. Components like `quser`, `qsh`, and `libc` are identical across both kernel variants. This 'seam' where the kernels differ demonstrates how higher-level OS services can be decoupled from specific kernel implementations, enabling architectural flexibility and easier experimentation with different kernel security models or performance characteristics.
Addressing System Deadlocks
The development process revealed and addressed critical system deadlocks, particularly when spawning programs from mounted NVMe storage. Initially, the `taskman` (task manager) was involved in routing wake-ups for I/O operations, leading to deadlocks when it was simultaneously blocked. The resolution involved routing device-interrupt pulses and Sync* slow paths directly to the kernel, bypassing `taskman` in the wake path. This decision is a classic example of optimizing critical paths in OS design to prevent contention and improve responsiveness, illustrating a fundamental trade-off between abstraction layers and performance/deadlock avoidance.