Hybrid kernel | EPFL Graph Search

A hybrid kernel is an operating system kernel architecture that attempts to combine aspects and benefits of microkernel and monolithic kernel architectures used in operating systems. The traditional kernel categories are monolithic kernels and microkernels (with nanokernels and exokernels seen as more extreme versions of microkernels). The "hybrid" category is controversial, due to the similarity of hybrid kernels and ordinary monolithic kernels; the term has been dismissed by Linus Torvalds as simple marketing. The idea behind a hybrid kernel is to have a kernel structure similar to that of a microkernel, but to implement that structure in the manner of a monolithic kernel. In contrast to a microkernel, all (or nearly all) operating system services in a hybrid kernel are still in kernel space. There are none of the reliability benefits of having services in user space, as with a microkernel. However, just as with an ordinary monolithic kernel, there is none of the performance overhead for message passing and context switching between kernel and user mode that normally comes with a microkernel. Architecture of Windows NT#Kernel One prominent example of a hybrid kernel is the Microsoft Windows NT kernel that powers all operating systems in the Windows NT family, up to and including Windows 11 and Windows Server 2022, and powers Windows Phone 8, Windows Phone 8.1, and Xbox One. Windows NT was the first Windows operating system based on a hybrid kernel. The hybrid kernel was designed as a modified microkernel, influenced by the Mach microkernel developed by Richard Rashid at Carnegie Mellon University, but without meeting all of the criteria of a pure microkernel. NT-based Windows is classified as a hybrid kernel (or a macrokernel) rather than a monolithic kernel because the emulation subsystems run in user-mode server processes, rather than in kernel mode as on a monolithic kernel, and further because of the large number of design goals which resemble design goals of Mach (in particular the separation of OS personalities from a general kernel design).

NrOS: Effective Replication and Sharing in an Operating System

Sanidhya Kashyap, Ankit Bhardwaj

Writing a correct operating system kernel is notoriously hard. Kernel code requires manual memory management and type-unsafe code and must efficiently handle complex, asynchronous events. In addition, increasing CPU core counts further complicate kernel development. Typically, monolithic kernels share state across cores and rely on one-off synchronization patterns that are specialized for each kernel structure or subsystem. Hence, kernel developers are constantly refining synchronization within OS kernels to improve scalability at the risk of introducing subtle bugs. We present NrOS, a new OS kernel with a safer approach to synchronization that runs many POSIX programs. NrOS is primarily constructed as a simple, sequential kernel with no concurrency, making it easier to develop and reason about its correctness. This kernel is scaled across NUMA nodes using node replication, a scheme inspired by state machine replication in distributed systems. NrOS replicates kernel state on each NUMA node and uses operation logs to maintain strong consistency between replicas. Cores can safely and concurrently read from their local kernel replica, eliminating remote NUMA accesses. Our evaluation shows that NrOS scales to 96 cores with performance that nearly always dominates Linux at scale, in some cases by orders of magnitude, while retaining much of the simplicity of a sequential kernel.

USENIX ASSOC2021

Advancing the State of Network Switch ASIC Offloading in the Linux Kernel

Andy Roulin

Modern data-center network operating systems rely on proprietary user-space daemons wrapping SDKs from switch vendors. Linux-based variants of these operating systems have benefited from increasing and simplified dataplane offloading support in recent years: kernel resources such as routes and next hops are offloaded to hardware and the kernel can, e.g., learn new MAC entries seen from the hardware forwarding plane. However, the Linux kernel in these operating systems has to be extended and customized as it still lacks constructs (constructs exposed to user-space or in-kernel constructs) needed for complete control plane processing and dataplane offloading. Managing limited hardware resources and keeping the kernel and hardware forwarding planes equivalent are two examples of challenges where the lack of appropriate constructs forces switch operating systems to use user-space solutions coupled with proprietary SDKs and custom kernel modifications. Filling the gaps, i.e., designing and adding the missing constructs, would enable faster control plane processing (less user-kernel context switches) and faster dataplane configura- tion. It would also encourage in-tree kernel drivers from hardware vendors instead of the current closed-source user-space SDKs which would also improve performance while estab- lishing Linux as the standardized API for network switches. This thesis explores the different designs, performance challenges and trade-offs of completing the in-kernel switching API, starting from switch port configuration, faster control path packet processing and ending with in-kernel ASIC resource management. As most hardware vendors are not yet ready to open their drivers in the kernel, workarounds to still provide support for vendors’ SDKs through the same in-kernel API are presented as well. A user-space switch port driver for Mellanox switches was ported to kernel space in order to accelerate control plane processing and bootstrap the in-kernel switch port configuration design. A prefetching scheme which hides PCI latency was designed to manage limited and shared ASIC resources with synchronous feedback to user-space daemons in case of exhausted resources.

2018

Advancing the State of Network Switch ASIC Offloading in the Linux Kernel

Andy Roulin

2018