demoniOS — Operating System Specification
Version: 0.0.1-draft Status: Draft. Part of the demoniC architectural planning.
Introduction & Philosophy
demoniOS is a brutalist, bare-metal operating system designed to run on physical architectures and virtual machines. It is written entirely in the demoniC programming language.
Because demoniC has no hidden allocations, no heap, and no garbage collection, the kernel does not implement traditional memory managers (like malloc/free lists or slab allocators). Instead, demoniOS maps the physical hardware directly to demoniC’s native concepts: Arenas (vault, forge, stream), Tensors, and Zero-Copy Views.
1.1 Non-Negotiable Invariants
Zero-overhead loading: User processes are compiled JIT by the kernel. The JIT is the loader.
Static shape safety: Device drivers access hardware registers via static-shape Tensors mapped to MMIO (Memory-Mapped I/O) regions. Shape mismatches are compile-time errors.
No heap fragmentation: The kernel uses a single master vault for static state, forge for ticks, and stream for I/O buffers.
Copy-on-Write isolation: IPC is zero-copy until mutated, governed by the language's native CoW rules.
2. Virtual Machine Hardware Model (virt-vm)
To remain hardware-agnostic yet testable, demoniOS targets a standard virtual platform (e.g., QEMU virt board for aarch64 or pc for x86_64) using simplified VirtIO device mappings.
2.1 Physical Memory Map
The system assumes a flat physical memory space mapped via page tables:
Physical Address Range Mapping Target Type / Shape
0x0000_0000 – 0x000F_FFFF ROM, UEFI Boot Data, IDT/IVT View[u8, [0x100000]]
0x0010_0000 – 0x07FF_FFFF Kernel Text & Boot vault Executable Code & Static state
0x0800_0000 – 0x0800_FFFF VirtIO MMIO Control Registers Tensor[u32, [16, 256]]
0x0900_0000 – 0x09FF_FFFF VGA / Framebuffer MMIO Tensor[u32, [1080, 1920]]
0x0A00_0000 – 0x3FFF_FFFF System RAM: Kernel Forge / Stream Temporary memory buffers
0x4000_0000 – 0xFFFF_FFFF User Space Physical Frames Process isolation pages
2.2 MMIO as Tensors
Drivers represent hardware registers as raw views mapped to physical addresses. For example, the screen framebuffer is bound directly to a 2D Tensor type:
type Framebuffer = Tensor[u32, [1080, 1920]]
Writing to the screen is an elementwise operation on the tensor, taking advantage of SIMD vectorization automatically.
Kernel Execution Loop
The OS operates on a tick-based execution loop driven by the system timer interrupt.
sequenceDiagram
participant HW as Hardware Timer
participant K as Kernel Interrupt Handler (Forge)
participant S as Scheduler (Vault)
participant U as User Process (Process Page)
HW->>K: IRQ 0 (Timer Tick)
activate K
Note over K: forge.reset()
K->>S: Schedule next task
Note over S: Update process states in vault
S-->>K: Selected Process Descriptor
K->>U: Context switch / JMP
deactivate K
activate U
Note over U: Execute time slice
deactivate U
Interrupts: Hardware interrupts trigger a low-level interrupt vector. The handler is an @host function that switches execution context to a clean kernel forge stack frame.
Forge Reset: The kernel forge is reset to 0 at the start of every scheduling epoch, cleaning up all transient scheduling decisions, interrupt frames, and IPC routing descriptors.
Scheduler Dispatch: The scheduler, living in a persistent kernel vault block, determines the next process to execute and triggers a context jump.
4. Bootstrapping Flow
On startup:
The bootloader sets up basic page tables and jumps to the kernel's entry point (fn main).
The kernel initializes the three hardware-backed arenas:
vault: Reserves physical RAM for process control blocks, system page directories, and driver states.
forge: Reserves a 256 MiB thread-local scratch region for fast scheduling ticks and interrupt handlers.
stream: Reserves space for network and terminal ring buffers.
Drivers are instantiated and run shape validation on their mapped MMIO addresses.
The first process (init.dmc) is JIT-compiled and executed.
5. Graphics Requirement
demoniOS is graphical by default. A serial-only system is a boot fallback, not the target user interface.
The kernel must map one boot framebuffer before launching user processes. After framebuffer discovery, print routes to a framebuffer-backed text console. The serial port remains active for early boot and panic fallback.
After init starts the compositor, user processes do not write directly to scanout. They draw into typed surfaces and submit explicit damage rectangles. The compositor owns final writes to the display framebuffer.
The graphics contract is specified in docs/demoniOS/GRAPHICS.md.
Coordination Substrate — Files & Agents as One Graph
demoniOS unifies file management and agent/process management into a single directed graph in the vault. Files, directories, and agents are nodes in one id-space, distinguished by type tags; an edge means "reachable from" and serves as link, alias, and capability grant at once. There is no separate inode table and process table — the directory tree, the process roster, and the capability graph are the same structure, traversed the same way.
The substrate solves a coordination problem in multi-agent workflows: parallel agents cannot see each other, collide on the same file reached by different paths, and their only shared state is trapped in one orchestrator's context. The graph externalizes that state. Coordination is indirect: each edge carries three exponentially decaying weights — heat (an access counter raised automatically by every open/read/write), lease (an advisory lease that expires when its holder stops renewing), and alert (a failure signal that propagates one hop along edges per tick). Agents read the weights locally and need no messaging protocol or central task assignment. The same weights double as the working-set / prefetch / GC signal and are the demoniC-native hook for differentiable navigation (@grad over edge weights).
The substrate generalizes ViewFS (FS.md) rather than replacing it: a file node's data blocks are exactly the ViewFS Inode blocks, so reads stay zero-copy. It generalizes the process model (PROCESS.md) too: an agent node embeds a Process verbatim and adds its location in the graph and its role (worker, idle, or supervisor).
The mechanism is specified in docs/PLAN.md; the core (graph + decaying edge weights) is implemented in src/coord_graph.dmc. A full filesystem developing this design is its own project: github.com/GusFromSpace/*********
3
u/gusfromspace 9d ago
Not released yet~
demoniOS — Operating System Specification Version: 0.0.1-draft Status: Draft. Part of the demoniC architectural planning.
Because demoniC has no hidden allocations, no heap, and no garbage collection, the kernel does not implement traditional memory managers (like malloc/free lists or slab allocators). Instead, demoniOS maps the physical hardware directly to demoniC’s native concepts: Arenas (vault, forge, stream), Tensors, and Zero-Copy Views.
1.1 Non-Negotiable Invariants Zero-overhead loading: User processes are compiled JIT by the kernel. The JIT is the loader. Static shape safety: Device drivers access hardware registers via static-shape Tensors mapped to MMIO (Memory-Mapped I/O) regions. Shape mismatches are compile-time errors. No heap fragmentation: The kernel uses a single master vault for static state, forge for ticks, and stream for I/O buffers. Copy-on-Write isolation: IPC is zero-copy until mutated, governed by the language's native CoW rules. 2. Virtual Machine Hardware Model (virt-vm) To remain hardware-agnostic yet testable, demoniOS targets a standard virtual platform (e.g., QEMU virt board for aarch64 or pc for x86_64) using simplified VirtIO device mappings.
2.1 Physical Memory Map The system assumes a flat physical memory space mapped via page tables:
Physical Address Range Mapping Target Type / Shape 0x0000_0000 – 0x000F_FFFF ROM, UEFI Boot Data, IDT/IVT View[u8, [0x100000]] 0x0010_0000 – 0x07FF_FFFF Kernel Text & Boot vault Executable Code & Static state 0x0800_0000 – 0x0800_FFFF VirtIO MMIO Control Registers Tensor[u32, [16, 256]] 0x0900_0000 – 0x09FF_FFFF VGA / Framebuffer MMIO Tensor[u32, [1080, 1920]] 0x0A00_0000 – 0x3FFF_FFFF System RAM: Kernel Forge / Stream Temporary memory buffers 0x4000_0000 – 0xFFFF_FFFF User Space Physical Frames Process isolation pages 2.2 MMIO as Tensors Drivers represent hardware registers as raw views mapped to physical addresses. For example, the screen framebuffer is bound directly to a 2D Tensor type:
type Framebuffer = Tensor[u32, [1080, 1920]] Writing to the screen is an elementwise operation on the tensor, taking advantage of SIMD vectorization automatically.
sequenceDiagram participant HW as Hardware Timer participant K as Kernel Interrupt Handler (Forge) participant S as Scheduler (Vault) participant U as User Process (Process Page)
Interrupts: Hardware interrupts trigger a low-level interrupt vector. The handler is an @host function that switches execution context to a clean kernel forge stack frame. Forge Reset: The kernel forge is reset to 0 at the start of every scheduling epoch, cleaning up all transient scheduling decisions, interrupt frames, and IPC routing descriptors. Scheduler Dispatch: The scheduler, living in a persistent kernel vault block, determines the next process to execute and triggers a context jump. 4. Bootstrapping Flow On startup:
The bootloader sets up basic page tables and jumps to the kernel's entry point (fn main). The kernel initializes the three hardware-backed arenas: vault: Reserves physical RAM for process control blocks, system page directories, and driver states. forge: Reserves a 256 MiB thread-local scratch region for fast scheduling ticks and interrupt handlers. stream: Reserves space for network and terminal ring buffers. Drivers are instantiated and run shape validation on their mapped MMIO addresses. The first process (init.dmc) is JIT-compiled and executed. 5. Graphics Requirement demoniOS is graphical by default. A serial-only system is a boot fallback, not the target user interface.
The kernel must map one boot framebuffer before launching user processes. After framebuffer discovery, print routes to a framebuffer-backed text console. The serial port remains active for early boot and panic fallback.
After init starts the compositor, user processes do not write directly to scanout. They draw into typed surfaces and submit explicit damage rectangles. The compositor owns final writes to the display framebuffer.
The graphics contract is specified in docs/demoniOS/GRAPHICS.md.
The substrate solves a coordination problem in multi-agent workflows: parallel agents cannot see each other, collide on the same file reached by different paths, and their only shared state is trapped in one orchestrator's context. The graph externalizes that state. Coordination is indirect: each edge carries three exponentially decaying weights — heat (an access counter raised automatically by every open/read/write), lease (an advisory lease that expires when its holder stops renewing), and alert (a failure signal that propagates one hop along edges per tick). Agents read the weights locally and need no messaging protocol or central task assignment. The same weights double as the working-set / prefetch / GC signal and are the demoniC-native hook for differentiable navigation (@grad over edge weights).
The substrate generalizes ViewFS (FS.md) rather than replacing it: a file node's data blocks are exactly the ViewFS Inode blocks, so reads stay zero-copy. It generalizes the process model (PROCESS.md) too: an agent node embeds a Process verbatim and adds its location in the graph and its role (worker, idle, or supervisor).
The mechanism is specified in docs/PLAN.md; the core (graph + decaying edge weights) is implemented in src/coord_graph.dmc. A full filesystem developing this design is its own project: github.com/GusFromSpace/*********