A kernel with interpreted processes

So this is my first post and in it, I will detail the kernel concept I have imagined which could be the first one with fully interpreted processes. So today I'm proud to present to you a new kernel concept, Shelter : Shelter Kernel Architecture Shelter is a highly modular and monolithic kernel designed to interpret processes directly through an internal language. Unlike traditional kernels that execute compiled binaries or system calls, Shelter integrates a native interpreter at its core, enabling more dynamic, secure, and fluid process execution. Core Structure At the heart of the kernel lies init, the backbone of the system. It acts both as the initializer for each module and the coordinator between them. init also handles multicore and multithreading management. The kernel is structured into two primary spaces: hardware space and software space, with init present and active at each layer. Hardware Space Level 1 – Port Abstraction Layer (PAL): Responsible for indexing and managing communication with hardware components. It abstracts low-level port interactions and serves as the foundation for hardware access. Level 2 – RAM Manager & Driver Manager: The RAM Manager manages the unique memory architecture of Shelter, which requires dedicated structural control. The Driver Manager handles all driver interactions and also manages file systems. Software Space Interpreter: At the top layer of the software space is the interpreter, responsible for executing user processes through the internal language. Session Manager: Each user process belongs to a session, ensuring strict separation and encapsulation of execution environments. Video Manager: Handles video output, multiscreen support, and graphics acceleration. Modular Daemon Units (.mdu): These include modules such as network.mdu, bluetooth.mdu, and audio.mdu. These are loaded after kernel initialization and provide APIs directly to user-space processes. Interruption Layer Bridging the hardware and software spaces is the Interruption Layer. It processes: Hardware interrupts, such as mouse clicks or keystrokes, routing them either to user-space processes or to relevant kernel modules. Software interrupts, originating from user processes or abstract kernel modules, and typically routed toward the RAM or Driver Managers. Each kernel module, whether critical (like those listed above) or auxiliary (such as additional .mdu modules), behaves like a lightweight library. .mdu modules are only called when explicitly needed by init or by another kernel module. User Space and Initialization In user space, only three kind of processes are foundational: The desktop environment The desktop manager, responsible for session login and management The user’s processes All hardware-related services are exclusively managed by the kernel. Any background process running in user space must have been manually installed by the user post-installation. Once the kernel has initialized, it hands over control to systeminit—a system-level user-space initializer. Comparable to systemd for Linux, it runs in ring 1.5 (see below) and is responsible for loading additional .mdu modules, initializing drivers, and launching the desktop manager. Security Rings The execution model in Shelter is governed by a strict ring-based security architecture: Ring 0: Kernel and core/.mdu modules Ring 1: Drivers (must interface with the kernel to access hardware) Ring 1.5: System ring for user-space processes needing elevated permissions (e.g., systeminit). Only processes created by other ring 1.5 processes can inherit this level. Ring 2: Admin user space (e.g., desktop environments, package managers). Ring 2 processes can only be created by ring 1.5 processes or by authenticated admin users via uac.mdu. Ring 3: Standard user space. Processes in this ring cannot escalate to ring 2. This ring architecture enforces a clear separation of responsibilities, enhances security, and ensures that privilege escalation is tightly controlled and always mediated by kernel-managed processes. Kernel Code Language Shelter introduces a dedicated low-level interpreted language known as Code Kernel, designed specifically for direct execution within the kernel environment. This language features an extremely minimalistic syntax to enable high-speed interpretation and reduce overhead. Despite its simplicity, it includes key constructs for managing program flow and memory: Exception handling Function definitions and calls Dynamic variables Buffers (essentially typed or untyped lists) Code Kernel does not use explicit data types for variables. This design decision favors runtime flexibility and faster interpretation, eliminating the need for static type checking or casting. The instruction set is a hybrid of low-level ISA-like commands (inspired by real-world processor architectures) and more abstract, h

Apr 4, 2025 - 19:02

So this is my first post and in it, I will detail the kernel concept I have imagined which could be the first one with fully interpreted processes.
So today I'm proud to present to you a new kernel concept, Shelter :

Shelter Kernel Architecture

Shelter is a highly modular and monolithic kernel designed to interpret processes directly through an internal language. Unlike traditional kernels that execute compiled binaries or system calls, Shelter integrates a native interpreter at its core, enabling more dynamic, secure, and fluid process execution.

Core Structure

At the heart of the kernel lies init, the backbone of the system. It acts both as the initializer for each module and the coordinator between them. init also handles multicore and multithreading management. The kernel is structured into two primary spaces: hardware space and software space, with init present and active at each layer.

Hardware Space

Level 1 – Port Abstraction Layer (PAL): Responsible for indexing and managing communication with hardware components. It abstracts low-level port interactions and serves as the foundation for hardware access.
Level 2 – RAM Manager & Driver Manager:
- The RAM Manager manages the unique memory architecture of Shelter, which requires dedicated structural control.
- The Driver Manager handles all driver interactions and also manages file systems.

Software Space

Interpreter: At the top layer of the software space is the interpreter, responsible for executing user processes through the internal language.
Session Manager: Each user process belongs to a session, ensuring strict separation and encapsulation of execution environments.
Video Manager: Handles video output, multiscreen support, and graphics acceleration.
Modular Daemon Units (.mdu): These include modules such as network.mdu, bluetooth.mdu, and audio.mdu. These are loaded after kernel initialization and provide APIs directly to user-space processes.

Interruption Layer

Bridging the hardware and software spaces is the Interruption Layer. It processes:

Hardware interrupts, such as mouse clicks or keystrokes, routing them either to user-space processes or to relevant kernel modules.
Software interrupts, originating from user processes or abstract kernel modules, and typically routed toward the RAM or Driver Managers.

Each kernel module, whether critical (like those listed above) or auxiliary (such as additional .mdu modules), behaves like a lightweight library. .mdu modules are only called when explicitly needed by init or by another kernel module.

User Space and Initialization

In user space, only three kind of processes are foundational:

The desktop environment
The desktop manager, responsible for session login and management
The user’s processes

All hardware-related services are exclusively managed by the kernel. Any background process running in user space must have been manually installed by the user post-installation.

Once the kernel has initialized, it hands over control to systeminit—a system-level user-space initializer. Comparable to systemd for Linux, it runs in ring 1.5 (see below) and is responsible for loading additional .mdu modules, initializing drivers, and launching the desktop manager.

Security Rings

The execution model in Shelter is governed by a strict ring-based security architecture:

Ring 0: Kernel and core/.mdu modules
Ring 1: Drivers (must interface with the kernel to access hardware)
Ring 1.5: System ring for user-space processes needing elevated permissions (e.g., systeminit). Only processes created by other ring 1.5 processes can inherit this level.
Ring 2: Admin user space (e.g., desktop environments, package managers). Ring 2 processes can only be created by ring 1.5 processes or by authenticated admin users via uac.mdu.
Ring 3: Standard user space. Processes in this ring cannot escalate to ring 2.

This ring architecture enforces a clear separation of responsibilities, enhances security, and ensures that privilege escalation is tightly controlled and always mediated by kernel-managed processes.

Kernel Code Language

Shelter introduces a dedicated low-level interpreted language known as Code Kernel, designed specifically for direct execution within the kernel environment. This language features an extremely minimalistic syntax to enable high-speed interpretation and reduce overhead. Despite its simplicity, it includes key constructs for managing program flow and memory:

Exception handling
Function definitions and calls
Dynamic variables
Buffers (essentially typed or untyped lists)

Code Kernel does not use explicit data types for variables. This design decision favors runtime flexibility and faster interpretation, eliminating the need for static type checking or casting. The instruction set is a hybrid of low-level ISA-like commands (inspired by real-world processor architectures) and more abstract, high-level operations tailored for the kernel’s execution model.

Code written in Code Kernel is always stored in plaintext and is directly interpretable by the kernel interpreter. Every kernel-level process or script runs natively in this format, offering complete transparency and enabling direct debugging or auditing of any kernel-executed code.

However, writing directly in Code Kernel is not intended for most developers. Due to its bare-metal nature and strict syntax, a companion language—Vodka—has been developed. Vodka is a higher-level language that introduces:

Type-safe variables
Classes and structured data
A simplified yet expressive syntax

Vodka code is not interpreted at runtime. Instead, it is transcoded into Code Kernel before execution. This preserves the performance benefits of Code Kernel while offering a more accessible programming experience for developers working on kernel-level modules or system services.

The existence of both languages allows for a clean separation between developer ergonomics and system performance, ensuring that the kernel remains lightweight, efficient, and entirely interpretable.

Modular Daemon Units (.mdu)

To address the limitations of Kernel Code when dealing with high-level abstractions such as networking, audio, or filesystem access, Shelter uses Modular Daemon Units (.mdu). These are the only compiled programs allowed to run natively in ring 0, and their purpose is tightly scoped: handling interrupts, serving user-space processes, or providing low-level services not feasible through interpreted kernel code.

Importantly, .mdu modules cannot replace hardware drivers. Although they can interact with hardware through the Shelter API, Shelter restricts their CPU access to isolated RAM regions and disables direct I/O access. This ensures stability and security. Only actual drivers (which are interpreted by default if not handled by a Secure and Adaptive Driver) are authorized to describe how to interface with hardware.

A core performance advantage of the .mdu system is that these modules do not run continuously. They are executed only in response to hardware or software interrupts, minimizing background activity and drastically improving performance for interpreted user-space processes. .mdu modules can be called by user-space processes with an unique instruction for all modules.

So here is the concept. Hope you will enjoy it and give me some feedback and opinion if you're interested.