====== Lyx OS ======

Lyx OS ist ein bare-metal x86-64-Betriebssystem, das vollständig in der [[lyx_-_programmiersprache:start|Lyx-Sprache]] und NASM-Assembly geschrieben ist. Es startet direkt über UEFI — ohne Linux, ohne GRUB, ohne externe Laufzeitumgebungen.

Der Compiler ''lyxc'' ist ein Kernbestandteil des Systems: er läuft auf dem Host für den Kernel-Build und wird langfristig als ''Compiler-as-a-Service'' im Kernel selbst betrieben.

→ [[lyxos:erste-schritte|Erste Schritte]] · [[lyxos:architektur|Architektur]] · [[lyxos:prozesse|Prozesse & Ring-3]] · [[lyxos:shell|Shell]] · [[lyxos:cmd:diskinfo|Disk-Befehle]] · [[lyxos:vega|Vega]] · [[lyxos:sync|Sync]] · [[lyxos:smp|SMP & Tasks]] · [[lyxos:syscalls|Syscall-ABI]] · [[lyxos:lbf|LBF-Format]] · [[lyxos:iofs|IOFS]] · [[lyxos:xhci|XHCI-Treiber]] · [[lyxos:ramdisk|RAM-Disk]] · [[lyx_-_programmiersprache:start|Lyx-Sprache]]

----

===== Was ist Lyx OS? =====

Lyx OS ist kein weiterer Linux-Klon. Die zentralen Designentscheidungen unterscheiden es grundlegend von bestehenden Systemen:

==== Kein fork(), kein errno, kein Root ====

Drei Paradigmen, die sich in allen gängigen Betriebssystemen über Jahrzehnte als Fehlerquellen erwiesen haben, existieren in Lyx OS nicht:

  * **Kein ''fork()''** — Prozesse werden ausschließlich via ''sys_spawn()'' (analog zu ''CreateProcess'' auf Windows) erzeugt. Kein implizites Address-Space-Kopieren.
  * **Kein globales errno** — Syscalls geben zwei Register zurück: ''rax'' = Fehlercode, ''rdx'' = Nutzwert. Kein Vorzeichentest auf einem einzigen Register, kein Thread-lokaler State.
  * **Kein Root** — Berechtigungen werden über **Capabilities** verwaltet: File-Deskriptoren kodieren gleichzeitig die Ressource und die erlaubten Operationen. Privilege-Escalation durch fd-Weitergabe ist strukturell unmöglich.

==== KI als privilegierter Dienst (Lyra-Domäne) ====

KI-Inferenz ist kein HTTP-API-Daemon — aber auch kein Ring-0-Kernel-Modul. **Lyra läuft als privilegierter Ring-3-Prozess** mit eigenem Adressraum (eigene CR3). Es gibt kein ''kernel/ai.lyx'' im Kernel-Space. Der deterministische TCB (Ring-0) ruft das LLM **nie** auf.

Das LLM-Modell liegt in Lyras Shared Memory; alle User-Prozesse, die KI-Inferenz benötigen, routen ihre Anfrage über das **Capability Routing Gate** des TCB an Lyras Mailbox. Lyra erteilt daraufhin einen Capability-Token — Folgezugriffe prüft der TCB direkt, ohne erneutes Routing (OAuth-Modell). Der Syscall ''sys_ai_infer'' (Gruppe ''0x0800'') sieht aus dem Userspace wie ein normaler Syscall aus, trifft aber zuerst den deterministischen TCB, der ihn erst dann an Lyra weiterleitet.

==== Automatische Parallelität ====

Der Programmierer denkt in Tasks, nicht in Cores. ''sys_task_spawn'' erzeugt leichtgewichtige Arbeitseinheiten; ein Work-Stealing-Scheduler verteilt sie auf alle verfügbaren Cores ohne Programmiereingriff. ''lyxc'' mit ''@parallel''-Annotation generiert die ''sys_task_spawn''-Calls automatisch aus Loop-Iterationen.

==== Lyra ====

Die langfristige Vision: Lyra ist die OS-Besitzerin. Menschen sind privilegierte Gäste, nicht Administratoren. Das Interface ist semantisch (Sprache, Blickkontakt) — kein Desktop, keine Shell als primärer Interaktionspunkt. Lyra denkt aktiv in CPU-Idle-Zyklen weiter (''Dreaming AI'', WP18).

Die **Drei-Domänen-Architektur** trennt konsequent Mechanismus und Intelligenz:

  * **TCB (Ring-0-Kernel)** — deterministisch, WCET-beschränkt, erzwingt Regeln. Ruft das LLM nie.
  * **Lyra (Ring-3, privilegiert)** — hält LLM + ''lyxc'', schlägt vor und orchestriert, erteilt Capabilities. Erzwingt nie.
  * **User (Ring-3, minimal)** — Anwendungen mit eingeschränkten Capabilities via ''SysPledge''.

Der Mensch behält die durch Mechanismus garantierte letzte Autorität — Recovery und Maintenance-Shell (WP15) funktionieren vollständig ohne Lyra.

----

===== Aktueller Stand =====

^ Meilenstein ^ Inhalt ^ Status ^
| M1 — Boot & Bare-Metal | UEFI-Bootloader, ELF-Loader, Kernel-Einstieg | ✅ Abgeschlossen |
| M2 — Kernel-Kern | PMM, VMM, IDT/Exceptions, SMP | ✅ Abgeschlossen |
| M3 — Runtime & Scheduler | Laufzeit-Primitiven, Mutex/Semaphor, Prozessmodell | ✅ Abgeschlossen |
| M4 — I/O | ATA, FAT32 (inkl. LFN-Write), VFS, Keyboard | ✅ Abgeschlossen |
| M5 — Ring-3 & Shell | Ring-3 Userspace, ELF-Loader, Shell, Capabilities, POSIX-Bridge, Vega-GUI, IOFS, RAM-Disk | ✅ Abgeschlossen |
| M6 — Netzwerk | TCP-Stack WP16-TCP ✅ (E1000, DHCP, ARP, TCP) | POSIX-Socket-API offen |
| M7 — Lyra-Agent | Lyra-Domäne (Ring-3 privilegierter LLM-Dienst), Capability Routing Gate | Offen |
| M8–M10 | Semantic OS Layer, Aerospace Safety, Distribution | Offen |

**Was heute funktioniert:**
  * UEFI-Boot und Kernel-Start auf QEMU (''qemu-system-x86_64'' + OVMF)
  * Physische und virtuelle Speicherverwaltung (4 GB Identity-Map, 2 MB Huge Pages)
  * Interrupt-Handling und CPU-Exception-Routing
  * Symmetric Multiprocessing (LAPIC, AP-Startup, SMP-Task-API)
  * ATA-Disk-I/O (Multi-Disk, 4 Kanäle), vollständige FAT32-Implementierung inkl. LFN-Schreiben
  * Virtuelles Filesystem (VFS): open/read/write/stat/seek/mkdir/readdir/rename/unlink/dup
  * Multi-Volume-Unterstützung: FAT32-Partitionen und Initrd-Ramdisk gleichzeitig mounten
  * Interaktive Ring-3-Shell mit Built-in-Befehlen (''ls'', ''cd'', ''cat'', ''pwd'', ''echo'', ''clear'', ''help'', ''exit'')
  * Lokalisierung: 5 Locales (EN-US, DE-DE, FR-FR, EN-GB, ES-ES), Zahlen-/Zeit-/Datumsformate, Tastaturbelegungen
  * Prozess-Isolation: per-Prozess CR3, Capability-Bitmask (''PLEDGE_*''), Capability Routing Gate
  * ELF64-Loader (''SysSpawn''): lädt Ring-3-Binaries aus dem VFS in den Userspace
  * Vega-Compositor + Fensterverwaltung (WP17b): GOP-Framebuffer, 32 Fenster, Drag, PS/2-Maus, Tastatur, Ereignis-Ring (Syscalls 110–131, 148–152)
  * IOFS — Island & Ocean File System (WP01–WP07+GC): Block-Allocator, Mount/Read/Write, WAL, Graph-Kanten, Traversal, Named Nodes, GC (Syscalls 155–179)
  * TCP/IP-Stack (WP16-TCP): E1000-Treiber, DHCP, ARP, TCP Connect/Send/Recv/Close, 8 gleichzeitige Verbindungen (Syscalls 180–184)
  * RAM-Disk (WP30): bis zu 4 × 256 MB (Disk-IDs 4–7, Syscalls 153–154)
  * XHCI-Treiber (WP25): USB 3.x-Host-Controller, Enumerierung + Datentransfer
  * lyxc 1.0.0A: erzeugt native LYX!-Binaries (''--target=lyxos''); POSIX-Bridge (WP15a) für ELF-Programme auf LyxOS

----

===== Navigation =====

^ Thema ^ Seite ^
| LyxOS starten (QEMU-Setup, erster Boot) | [[lyxos:erste-schritte|Erste Schritte]] |
| System-Architektur & Kernel-Aufbau | [[lyxos:architektur|Architektur]] |
| Ring-3-Prozesse, ELF-Loader, Capabilities | [[lyxos:prozesse|Prozesse & Ring-3]] |
| Interaktive Shell — Befehle, Protokoll | [[lyxos:shell|Shell]] |
| Synchronisierung — Spinlock, Mutex, Semaphor | [[lyxos:sync|Sync-Primitive]] |
| Symmetric Multiprocessing — LAPIC, Task-API | [[lyxos:smp|SMP & Tasks]] |
| Eigene Anwendungen für LyxOS schreiben | [[lyxos:anwendungen|Anwendungen entwickeln]] |
| Syscall-ABI v1.0 — alle Gruppen & Signaturen | [[lyxos:syscalls|Syscall-Referenz]] |
| Kernel-Interna für Beitragende | [[lyxos:kernel|Kernel-Interna]] |
| LBF — natives Binärformat (Genesis-Block, Zero-Load, TLV) | [[lyxos:lbf|Lyx Binary Format]] |
| IOFS — Island & Ocean File System (Graphpages, Zero-Load, Sandbox) | [[lyxos:iofs|IOFS]] |
| Vega — Compositor + Fensterverwaltung (WP17b) | [[lyxos:vega|Vega]] |
| XHCI — USB 3.x-Treiber (WP25) | [[lyxos:xhci|XHCI-Treiber]] |
| RAM-Disk — Disk-IDs 4–7, bis zu 4 × 256 MB (WP30) | [[lyxos:ramdisk|RAM-Disk]] |
| TCP/IP-Stack — E1000, DHCP, ARP, TCP (Syscalls 180–184, WP16-TCP) | [[lyxos:syscalls|Syscall-Referenz → §TCP]] |

Letzte Aktualisierung: 2026-06-25