Lyx OS

UEFI • x86-64 • In Lyx geschrieben • Kein fork() • Kein errno • Kein Root • KI als Kernel-Primitiv

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

Drei fundamentale Design-Entscheidungen unterscheiden Lyx OS grundlegend von bestehenden Systemen:

• Kein fork() — Prozesse werden ausschließlich via sys_spawn() erzeugt. Kein implizites Address-Space-Kopieren, kein exec-nach-fork-Muster.
• Kein globales errno — Syscalls geben zwei Register zurück: rax = Fehlercode, rdx = Nutzwert. Kein Vorzeichentest auf einem einzigen Register, kein Thread-lokaler Fehler-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-Inferenz ist in Lyx OS kein Userspace-Daemon und kein HTTP-API — sie ist ein schedulierter Kernel-Workload. Ein Sprachmodell wird einmal in Kernel-verwaltetem Shared Memory geladen; alle Prozesse nutzen es ohne Kopie und ohne IPC-Roundtrip. Der sys_ai_infer-Syscall (Gruppe 0x0800) ist genauso normal wie sys_read.

Das ermöglicht die langfristige Vision Lyra: eine KI-Besitzerin des Betriebssystems, die in CPU-Idle-Zyklen aktiv weiterdenkt und Ressourcen semantisch verwaltet — nicht als App auf einem OS, sondern als integraler Bestandteil des Kernels.

fn main(): int64 {
    // Modell laden (OS-weit geteilt, kein doppelter Speicher)
    var model_fd: int64 := sys_ai_model_load(AT_CWD, "/models/lyra-7b.gguf", 0);
    var ctx_fd:   int64 := sys_ai_ctx_create(model_fd, 0, 0);

    // Synchrone Inferenz — blockiert bis Completion
    var result: [4096]uint8 := [];
    sys_ai_infer_sync(ctx_fd, "Was ist 2+2?", 12, ^result[0], 4096, null);
    PrintLn(^result[0] as pchar);

    return 0;
}

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

// Jede Iteration läuft auf einem beliebigen Core — ohne manuelles Threading
@parallel for i in range 0..1000 {
    result[i] := process(data[i]);
}

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 via INIT+SIPI)
• ATA-Disk-I/O und vollständige FAT32-Implementierung (~795 Zeilen)
• Ring-3-Userspace (shell.lyx aktiv, gibt Startup-Meldung aus)
• Syscall-ABI v1.0 vollständig spezifiziert (137 Syscalls in 13 Kategorien)

# Repository klonen und bauen
git clone https://github.com/lyxos/lyx-os.git
cd lyx-os
bash bootloader/build.sh

# In QEMU starten
bash bootloader/run.sh

Erwartete Ausgabe:

Lyx OS v0.1 - Kernel running
PMM: init... free pages: 65432
VMM: identity map + CR3 load... CR3=0x200000 OK
Exceptions: IDT loaded (256 gates)
SMP: 4 CPUs detected, APs started
ATA: disk ready  |  FAT32: init OK  |  VFS: mounted  |  Keyboard: ready
Lyx Shell v0.1 - Ring-3 active

→ Vollständige Anleitung: Voraussetzungen, Build-Schritte, Debugging

Ring-3-Programme für LyxOS werden mit –target=lyxos kompiliert. Das Target löst alle Builtins (PrintLn, mmap, open, …) direkt auf LyxOS-Syscalls auf — keine libc, kein CRT0.

fn main(): int64 {
    PrintLn("Hallo von Ring-3!");
    return 0;
}

lyxc --target=lyxos hello.lyx -o hello.elf

→ Anwendungen entwickeln — Dateisystem, Speicher, Prozesse, Fehlerbehandlung

Lyx OS definiert 137 Syscalls in 13 Kategorien. Das Design-Prinzip: ein Syscall = eine Operation, kein polymorpher Wildwuchs wie Linux ioctl/fcntl.

→ Vollständige Syscall-Referenz — alle Kategorien, Signaturen, Fehlercodes

Letzte Aktualisierung: 2026-06-09