Lyx OS – IOFS: Island & Ocean File System

IOFS ist das native Dateisystem von Lyx OS. Es ersetzt FAT32 als primären Speicher und ist von Grund auf für drei Anforderungen gebaut: Zero-Load-Ausführung (LBF-Binaries laufen direkt aus dem Speicher, ohne Kopieren), graphbasierte Abhängigkeitsverwaltung (Pages sind Knoten, Abhängigkeiten sind typisierte Kanten) und semantische Suche (jede Page kann mit Embeddings annotiert werden).

→ LBF-Binärformat · Syscall-ABI 0x0C00 · Architektur · Übersicht

┌──────────────────────────────────────────────────────────────┐
│  OCEAN  (gesamtes Block-Device)                              │
│                                                              │
│  ┌──────────────────┐  ┌──────────────────┐                 │
│  │  Island "system" │  │  Island "tools"  │  ...            │
│  │                  │  │                  │                  │
│  │  Page 0x0001     │  │  Page 0x4A01     │                 │
│  │  Page 0x0002 ────┼──┼─► Page 0x4A02   │  (Graph-Kante)  │
│  │  ...             │  │  ...             │                  │
│  └──────────────────┘  └──────────────────┘                 │
└──────────────────────────────────────────────────────────────┘

Jede IOFS-Page beginnt mit einem 32-Byte-Header:

Offset  Größe  Feld           Beschreibung
──────  ─────  ─────────────  ─────────────────────────────────────────────
0x0000  4      magic          "LYX!" (0x4C 0x59 0x58 0x21) — gleich wie LBF
0x0004  1      page_type      Typ der Page (siehe Tabelle unten)
0x0005  3      reserved       Reserviert, muss 0 sein
0x0008  8      lpid           Logical Page ID dieser Page
0x0010  4      crc32c         CRC32C über Bytes 0x0020–0x0FFF (Nutzdaten)
0x0014  4      payload_len    Größe der Nutzdaten in Bytes (max. 4064)
0x0018  8      prev_lpid      LPID der Vorgänger-Page (für verkettete Cluster; 0 = keine)
0x0020  4064   payload        Nutzdaten

con IOFS_PAGE_FREE   : uint8 := 0x01
con IOFS_PAGE_DATA   : uint8 := 0x02
con IOFS_PAGE_META   : uint8 := 0x03
con IOFS_PAGE_EXEC   : uint8 := 0x04
con IOFS_PAGE_GRAPH  : uint8 := 0x05
con IOFS_PAGE_CONT   : uint8 := 0x06
con IOFS_PAGE_ISLAND : uint8 := 0x07

Die Kernleistung von IOFS ist die O(1)-Übersetzung eines LPIDs in eine physische LBA (Logical Block Address). Der Kernel hält eine kompakte In-Memory-Tabelle, die LIP-Tabelle (*Logical Island Page*):

lip_get(lpid)  →  lba          O(1) — direkter Array-Zugriff
lba × 4096     →  Byte-Offset  auf dem Block-Device

Im Zero-Load-Modus (→ LBF-Format, Abschnitt 6) trägt der Kernel diese LBAs direkt als physische Adressen in die CPU-Page-Tables (CR3) ein. Die CPU greift auf LBF-Code-Pages zu, als wären sie RAM — ohne eine einzige Kopie.

// Kernel-internes API (nicht als Syscall exponiert):
var lba: int64 := lip_get(block_lpid);
// pte.phys_addr = lba × 4096
// pte.flags     = PROT_READ | PROT_EXEC   (für .text-Pages)

Jede Page kann als Knoten im Kernel-Wissensgraphen (→ Syscalls 0x080F–0x0812) registriert werden. IOFS definiert zwei eingebaute Kanten-Typen für die LBF-Integration:

con IOFS_EDGE_LBF_CHAIN : int64 := 0xB001
con IOFS_EDGE_LBF_DEP   : int64 := 0xD001

Weitere Kanten-Typen werden von höheren Schichten vergeben (z.B. semantische Ähnlichkeit durch den AI-Subsystem-Layer in M7+). Die Kanten werden im Kernel-Wissensgraph (sys_graph_*) gespeichert — IOFS selbst speichert nur die rohen Page-Daten.

IOFS führt einen Hash-Index über alle Genesis-Pages (Typ 0x04). Schlüssel ist der SHA-256-Hash der Quelldateien (source_sha256 aus dem LBF-Genesis-Header), Wert ist der LPID der entsprechenden Page.

Anwendung: Der LBF-Loader löst DEP_HASH_GRAPH-Einträge (TLV 0x02) ohne Verzeichnis-Traversierung auf — er berechnet den SHA-256 der Abhängigkeit und schlägt direkt im Hash-Index nach. Kein symbolisches Linking, keine Pfad-Suche.

import-Auflösung:
  sha256(dep.source) → lip_index_lookup() → lpid → lba
  kein ld.so, kein PATH-Scan, kein symbolisches Linking

Beim Import eines LBF-Binaries via lbf_import läuft der Omni-Ingest-Prozess:

1. LBF-Blöcke werden als IOFS-Pages gespeichert (Typ 0x04 für Genesis, 0x02 für Code-/Daten-Pages)
2. Der HUMAN_INTENT-Text (TLV 0x01 aus dem Genesis-Block) wird durch das KI-Subsystem in einen Embedding-Vektor umgewandelt
3. Der Embedding-Vektor wird an die Genesis-Page annotiert (sys_sem_annotate)
4. Die Page wird im Kernel-Wissensgraph registriert (sys_graph_node_create)
5. Graph-Kanten werden zwischen den LBF-Blöcken gewoben

Nach dem Ingest ist das Programm über sys_ai_search (semantische Ähnlichkeit) und sys_timeline_query (zeitbasiert) auffindbar — ohne dass der User den genauen Dateinamen kennen muss.

lbf_import main.lbf --into-island="tools"
→ IOFS-Pages anlegen
→ Omni-Ingest: Embedding + Graph-Registrierung
→ Hash-Index aktualisieren

Die Panic-Sandbox ist ein IOFS-Modus für die Vertrauenskette des LBF-Loaders (→ LBF-Format, Abschnitt 5).

• sys_iofs_sandbox_enter (CAP_ADMIN erforderlich) aktiviert den Modus: IOFS verweigert alle Schreiboperationen außer dem Aktualisieren der Compiler-Blacklist
• In diesem Modus können kompromittierte Compiler-UUIDs sicher zur Blacklist hinzugefügt werden, ohne dass ein laufender Angriff die Liste manipulieren kann
• sys_iofs_sandbox_exit verlässt den Modus

Beim LBF-Import prüft der Kernel automatisch: Ist die compiler_instance_sn (UUID aus dem Genesis-Block) in der Blacklist? Falls ja, wird der Import abgelehnt — Schicht 3 der 5-Schichten-Vertrauenskette.

IOFS ist ein Append-Only-System: gelöschte oder veraltete Pages werden nicht sofort überschrieben, sondern als IOFS_PAGE_FREE markiert. Ein periodischer oder manueller Kompaktierungszyklus defragmentiert das Volume:

var mount_fd: int64 := ...;
// region_hint = 0: gesamtes Volume kompaktieren
var freed_pages: int64 := 0;
var err: int64 := 0;
// (err, freed_pages) := syscall(SYS_IOFS_COMPACT, mount_fd, 0);

sys_iofs_compact (0x0C01) gibt die Anzahl der zurückgewonnenen Pages zurück. Der Kernel kann diesen Zyklus auch automatisch im Hintergrund auslösen (konfigurierbar über IofsOpts beim Mount).

Die Low-Level-IOFS-Syscalls sind für Systemtools und den Kernel selbst. Normale Anwendungen gehen über das VFS-Interface (0x0200–0x0215).

Ring-3-Anwendungen
        │
        ▼  sys_open / sys_read / sys_write  (0x0200)
  ┌─────────────┐
  │     VFS     │   Abstraktionsschicht — kennt kein Dateisystem direkt
  └──────┬──────┘
         │
    ┌────┴────┐
    │         │
    ▼         ▼
  FAT32     IOFS      ← beide als VFS-Backends mountbar
 (M1–M4)   (M5+)

FAT32 bleibt für den UEFI-Boot (BOOTX64.EFI und kernel.elf auf der EFI-Partition) und als Kompatibilitätsmodus erhalten. Ab M5 ist IOFS das primäre Volume für alle Anwendungen und KI-Modelle. Das VFS-Interface (sys_open/sys_read usw.) bleibt unverändert — der Wechsel ist für Ring-3-Code transparent.

IOFS ist ab M5 geplant. In M1–M4 gilt:

• Das Kernel-Dateisystem ist ausschließlich FAT32 (via fat32.lyx und vfs.lyx)
• sys_iofs_*-Syscalls (0x0C00–0x0C04) geben in M1–M4 ERR_NOSYS zurück
• Die LBF-Zero-Load-Ausführung ist ab M5 mit dem IOFS-Treiber verfügbar; bis dahin lädt ring3.lyx LBF-Binaries sequentiell via FAT32/VFS

Letzte Aktualisierung: 2026-06-10