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 ist exakt 4096 Bytes groß. Der Page-Header belegt die ersten 64 Bytes (0x00–0x3F), das Payload beginnt bei Offset 0x40:

Offset  Größe  Feld              Beschreibung
──────  ─────  ────────────────  ─────────────────────────────────────────────
0x0000  4      magic             "LYX!" (0x4C 0x59 0x58 0x21)
0x0004  1      type              Page-Typ (IOFS_TYPE_*)
0x0005  1      flags             Page-Flags (IOFS_FLAG_*)
0x0006  2      edge_offset (LE)  Byte-Offset der Kanten-Liste in der Page (0x0040 = kein Kantenblock)
0x0008  8      lpid (LE)         Logical Page ID dieser Page
0x0010  2      payload_size (LE) Größe der Nutzdaten in Bytes (max. 4032)
0x0012  2      (reserviert)      Muss 0 sein
0x0014  4      crc32c (LE)       CRC32C-Castagnoli über die gesamte 4096-Byte-Page (Feld beim Berechnen auf 0 gesetzt)
0x0018  8      cont_lpid (LE)    Continuation-LPID (0 = keine Fortsetzung; für Pages > 4032 Bytes)
0x0020  32     (reserviert)      Muss 0 sein
0x0040  4032   payload           Nutzdaten (ab Offset 64)

con IOFS_TYPE_META:       int64 := 1;
con IOFS_TYPE_DATA:       int64 := 2;
con IOFS_TYPE_EMBED:      int64 := 3;
con IOFS_TYPE_EDGE_LIST:  int64 := 4;  // WP05
con IOFS_TYPE_NAME_STORE: int64 := 5;  // WP07

con IOFS_FLAG_IMMUTABLE: int64 := 1;
con IOFS_FLAG_EPHEMERAL: int64 := 2;

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).

Das IOFS-Volume auf einem 64-MB-Datenträger ist in fünf feste Bereiche aufgeteilt. Alle Werte aus kernel/iofs_alloc.lyx:

Page      Bereich          Seiten  Beschreibung
────────  ───────────────  ──────  ─────────────────────────────────────
0         Superblock           1   "IOFS"-Magic + Layout-Konstanten
1         Root Node            1   LPID=1, "LYX!"-Magic, Type=Meta, Flag=Immutable
2–131     Checkpoint Slot A  130   1 Header + 1 Bitmap + 128 LIP-Pages (aktiv, seq=1)
132–261   Checkpoint Slot B  130   identische Struktur, beim mkfs genullt (inaktiv)
262–325   WAL                 64   Write-Ahead-Log, beim mkfs genullt
326–16383 Ocean            16058   allocierbar (≈ 62 MB)

con IOFS_TOTAL_PAGES:     int64 := 16384;   // 64 MB / 4096 B
con IOFS_SECTORS_PER:     int64 := 8;        // 4096 / 512  → LBA = page_idx * 8
con IOFS_MAX_LPID:        int64 := 65536;
con IOFS_BITMAP_BYTES:    int64 := 2048;     // ceil(16384 / 8)

con IOFS_PAGE_SUPER:      int64 := 0;
con IOFS_PAGE_ROOT:       int64 := 1;

con IOFS_SLOT_LIP_PAGES:  int64 := 128;     // MAX_LPID*8 / 4096
con IOFS_SLOT_PAGES:      int64 := 130;     // 1 Header + 1 Bitmap + 128 LIP
con IOFS_PAGE_SLOT_A:     int64 := 2;
con IOFS_PAGE_SLOT_B:     int64 := 132;

con IOFS_WAL_PAGES:       int64 := 64;
con IOFS_PAGE_WAL_START:  int64 := 262;
con IOFS_PAGE_WAL_END:    int64 := 325;

con IOFS_PAGE_OCEAN_START: int64 := 326;
con IOFS_PAGE_OCEAN_END:   int64 := 16383;
con IOFS_OCEAN_PAGES:      int64 := 16058;   // 16383 − 326 + 1

Offset  Größe  Feld              Wert bei mkfs
──────  ─────  ────────────────  ─────────────────────────────────────────
+0      4      magic             "IOFS" (0x49 0x4F 0x46 0x53)
+4      1      version_major     1
+5      1      version_minor     0
+8      8      total_pages       16384
+16     8      max_lpid          65536
+24     8      ocean_start       326
+32     8      ocean_end         16383
+40     8      slot_a            2
+48     8      slot_b            132
+56     8      wal_start         262
+64     8      wal_end           325
+72     8      slot_pages        130
+80     8      wal_pages         64
+88     8      sectors_per_page  8
+96     8      ocean_pages       16058

Jeder Slot beginnt mit einer Header-Page (Offset 0 im Slot):

Offset  Feld          Beschreibung
──────  ────────────  ────────────────────────────────────────────
+0      valid (1B)    1 = aktiv, 0 = inaktiv
+8      seq lo (1B)   Sequenz-Nummer (32-Bit LE, über Bytes +8..+11)
+16     bitmap_pages  1 (immer 1 Bitmap-Page)
+20     lip_pages lo  128 (LE, über Bytes +20..+21)

Crash-Atomarität: der Slot-Header wird zuletzt geschrieben. Bitmap + LIP-Pages werden vollständig auf Disk gebracht, bevor valid=1 gesetzt wird. Bei Absturz vor dem Header bleibt der Slot mit valid=0 ungültig.

WP04: Ab WP04 enthält der Slot-Header zusätzlich wal_seq_at_checkpoint bei Offset +24 (uint32 LE). IofsCheckpoint schreibt dort den aktuellen WalSeq()-Wert, bevor der Header auf Disk kommt. IofsMountDisk liest diesen Wert und übergibt ihn an WalInit(), damit WalReplay weiß, ab welcher Sequenznummer die WAL-Einträge nach dem letzten Checkpoint relevant sind.

128 LIP-Pages pro Slot bilden die LPID→page_idx-Tabelle:

lip_page[k] enthält int64-Einträge für LPID k*512 … k*512+511
  Eintrag j: page_idx des physischen Blocks für LPID (k*512+j)
             0 = nicht alloziert

Beim mkfs: LIP-Page 0 (Slot-Offset +2):
  Byte 0..7  = 0  (LPID 0 = kein Root)
  Byte 8..15 = 1  (LPID 1 = Root Node, page_idx=1)
  Rest       = 0
Alle weiteren LIP-Pages = 0

WP03 ergänzt eine vollständige CRC32C-Prüfsummen-Engine für alle IOFS-Pages.

Castagnoli CRC32C mit reflektiertem Polynom 0x82F63B78. Die Lookup-Tabelle (256 × uint32 = 1024 Bytes) wird beim ersten Aufruf von IofsAllocInit einmalig per mmap alloziert und befüllt (Guard: crc32c_table != 0).

CRC-Berechnung (Castagnoli):
  c = 0xFFFFFFFF
  for each byte b:
    idx = (c XOR b) & 0xFF
    c = (c >> 8) XOR table[idx]
  return (c XOR 0xFFFFFFFF) & 0xFFFFFFFF

Hinweis: Nur Pages mit „LYX!“-Magic werden geprüft. Superblock (Page 0) und WAL-Pages tragen kein „LYX!“-Magic und werden nicht via CRC verifiziert.

Der Block-Allocator verwaltet eine In-RAM-Bitmap (2048 Bytes) über alle 16384 Pages.

IofsAllocInit(disk_id) markiert die 326 reservierten Pages (p0–p325) als belegt, Ocean-Pages (p326–p16383) als frei. Legt den Hint auf IOFS_PAGE_OCEAN_START.

IofsMkfs(disk_id) (→ VfsMkfsIofs → Syscall 155 = sys_mkfs_iofs) schreibt das komplette IOFS-Volume in dieser Reihenfolge:

1. IofsAllocInit(disk_id) — Bitmap aufbauen
2. Superblock (Page 0): „IOFS“-Magic + alle Layout-Konstanten
3. Root Node (Page 1): „LYX!“-Magic, IOFS_TYPE_META, IOFS_FLAG_IMMUTABLE, LPID=1, payload=„IOFS_ROOT_v1.1“ (14 Bytes bei Offset 0x40)
4. WAL (Pages 262–325): alle Pages genullt
5. Checkpoint Slot A (Pages 2–131): Bitmap (p3), LIP-Page 0 mit LPID-1→p1 (p4), LIP-Pages 1–127 genullt (p5–p131), Header zuletzt (p2, valid=1, seq=1)
6. Checkpoint Slot B (Pages 132–261): vollständig genullt (Header valid=0)

Aufruf aus Ring-3:

import bsys;
// ...
var rc: int64 := SysMkfsIofs(disk_id);   // 0 = OK, -1 = Fehler

Aufruf als Shell-Tool:

> mkfs_iofs 1
mkfs_iofs: formatting disk 1 as IOFS... OK
  p0        Superblock
  p1        Root node (LPID=1)
  p2-131    Checkpoint slot A  (1 header + 1 bitmap + 128 LIP pages)
  p132-261  Checkpoint slot B  (inactive, zeroed)
  p262-325  WAL (64 pages, zeroed)
  p326-16383 Ocean (16058 free pages)

WP02 baut auf dem Block-Allocator (WP01) auf und liefert die vollständige LPID-basierte Lese-/Schreibschnittstelle sowie crash-atomare Checkpoints.

+0   (int64)  mounted       1 = gemountet, 0 = nicht gemountet
+8   (int64)  free_pages    Anzahl freier Ocean-Pages
+16  (int64)  mapped        Anzahl belegter LPIDs
+24  (int64)  active_slot   IOFS_PAGE_SLOT_A (2) oder IOFS_PAGE_SLOT_B (132)
+32  (int64)  seq           Aktuelle Checkpoint-Sequenz-Nummer
+40  (int64)  dirty         1 = ungespeicherte Änderungen vorhanden
+48  (int64)  wal_head      Nächster WAL-Schreib-Index (0–8191, zirkulär; WP04)
+56  (int64)  wal_seq       Nächste WAL-Sequenznummer (monoton ≥ 1; WP04)

SysIofsMount(disk_id):              int64   // nr=156
SysIofsReadLpid(lpid, buf):         int64   // nr=157; buf muss phys. Adresse sein
SysIofsWriteLpid(lpid, buf):        int64   // nr=158
SysIofsNewPage(type_, flags, payload, psize): int64  // nr=159
SysIofsFreeLpid(lpid):              int64   // nr=160
SysIofsCheckpoint():                int64   // nr=161
SysIofsUnmount():                   int64   // nr=162
SysIofsLipGet(lpid):                int64   // nr=163
SysIofsInfo(buf):                   int64   // nr=164; buf = 64-Byte-Puffer

Hinweis zu SysIofsReadLpid / SysIofsWriteLpid: Der Kernel übersetzt user_buf via VmmPhysFromUserVirt in eine physische Adresse. Der übergebene Puffer muss daher eine via mmap allozierte Page sein (kein Stack-Puffer).

> mkfs_iofs 1
mkfs_iofs: formatting disk 1 as IOFS... OK

> iofs mount 1
iofs: mounting disk_id=1 ... OK

> iofs alloc "Hallo IOFS"
iofs: allocated lpid=2

> iofs read 2
  magic    LYX! OK
  lpid     2
  type     1
  flags    0
  psize    10 bytes
  payload  Hallo IOFS

> iofs checkpoint
iofs: checkpoint ... OK

> iofs info
  mounted      yes   active slot A  seq=2
  free pages   16057 / 16058
  mapped LPIDs 2

WP04 ergänzt einen persistenten WAL-Ring für alle Mutationen an LIP-Tabelle und Bitmap. Damit sind Änderungen nach einem Checkpoint auch bei Absturz vor dem nächsten Checkpoint wiederherstellbar — ohne den vollständigen Dual-Slot-Flip abzuwarten.

pub con IOFS_WAL_TYPE_LIP_UPDATE:   int64 := 1;  // key=lpid,     value=new_page_idx
pub con IOFS_WAL_TYPE_BITMAP_SET:   int64 := 2;  // key=page_idx, value=0
pub con IOFS_WAL_TYPE_BITMAP_CLEAR: int64 := 3;  // key=page_idx, value=0

pub con IOFS_WAL_ENTRY_SZ: int64 := 32;   // Bytes je Eintrag
pub con IOFS_WAL_EPP:      int64 := 128;  // Einträge je 4096-Byte-Page
pub con IOFS_WAL_TOTAL:    int64 := 8192; // 64 Pages × 128 Einträge (zirkulär)

Offset  Größe  Feld    Beschreibung
──────  ─────  ──────  ──────────────────────────────────────────────────────────
0x00    1      type    0=leer, 1=LIP_UPDATE, 2=BITMAP_SET, 3=BITMAP_CLEAR
0x01    7      (pad)   Muss 0 sein
0x08    8      key     LPID (LIP_UPDATE) oder page_idx (Bitmap-Ops)
0x10    8      value   Neuer page_idx (LIP_UPDATE) oder 0 (Bitmap-Ops)
0x18    4      seq     Monotone Sequenznummer (uint32 LE, ≥ 1)
0x1C    4      crc32c  CRC32C über Bytes 0x00–0x1B (28 Bytes)

Stop-Heuristik beim Replay: type == 0 oder CRC-Fehler = Ende der geschriebenen Einträge.

1.  IofsAllocPage()               → new_pidx
2.  IofsWritePage(disk_id, new_pidx, buf)   ← physische Page auf Disk
3.  WalAppend(BITMAP_SET,   new_pidx, 0)    ← WAL: neuen Block als belegt markieren
4.  WalAppend(LIP_UPDATE,   lpid, new_pidx) ← WAL: LIP-Eintrag aktualisieren
5.  [falls alter Block vorhanden]
    WalAppend(BITMAP_CLEAR, old_pidx, 0)    ← WAL: alten Block als frei markieren
6.  LIP[lpid]  := new_pidx    ← jetzt RAM-Mutation
7.  Bitmap[new] := belegt
8.  Bitmap[old] := frei

Das WAL-Eintrag kommt vor der RAM-Mutation: bei Absturz nach Schritt 2 aber vor Schritt 6 rekonstruiert WalReplay beim nächsten Mount den korrekten Zustand.

IofsCheckpoint():
  1.  Bitmap → inaktiver Slot +1
  2.  128 LIP-Pages → inaktiver Slot +2..+129
  3.  wal_s := WalSeq()
  4.  Slot-Header mit valid=1, seq+1, wal_seq=wal_s → inaktiver Slot +0  ← zuletzt
  5.  WalZero(disk_id)         ← WAL-Pages leeren
  6.  WalInit(wal_s)           ← head=0, seq=wal_s

IofsMountDisk():
  1.  Aktiven Slot bestimmen (valid=1, höchste seq)
  2.  Bitmap + LIP laden
  3.  wal_seq_at_checkpoint := Slot-Header +24 (uint32 LE)
  4.  WalInit(wal_seq_at_checkpoint)
  5.  WalReplay(disk_id, wal_seq_at_checkpoint, lip, bmp)

Die WAL ist ein zirkulärer Ring mit 8192 Slots. Bei sehr hoher Write-Last ohne zwischenzeitlichen Checkpoint kann der Ring überlaufen — älteste Einträge werden überschrieben. Deshalb sollte IofsCheckpoint regelmäßig aufgerufen werden.

WP05 fügt eine gerichtete Kanten-Schicht auf IOFS-Pages auf. Jede Node-Page kann über ihr cont_lpid-Feld (Offset 0x18) auf eine verkettete Liste von Edge-List-Pages zeigen.

Node-Page (beliebiger Typ mit LYX!-Magic):
  +0x18  edge_list_lpid (int64)  — 0 = keine Kanten; >0 = LPID der ersten Edge-List-Page

Edge-List-Page (type = IOFS_TYPE_EDGE_LIST = 4):
  +0x08  lpid (int64)            — LPID dieser Edge-List-Page
  +0x10  payload_size (uint16)   — edge_count × IOFS_EDGE_SIZE
  +0x12  edge_count (uint16)     — Anzahl Einträge auf dieser Page
  +0x18  next_edge_page (int64)  — LPID der nächsten Page (0 = letzte)
  +0x40  Edge-Einträge           — 12 Bytes je Eintrag:
           0-7   to_lpid   (int64 LE)
           8-9   edge_type (uint16 LE)
           10-11 padding   (0x0000)

con IOFS_EDGE_SIZE:         int64 := 12;
con IOFS_EDGE_MAX_PER_PAGE: int64 := 336;   // (4096 - 64) / 12

Wenn eine Edge-List-Page voll ist (336 Einträge), wird transparent eine neue alloziert und via next_edge_page verkettet.

SysIofsEdgeAdd(from_lpid, to_lpid, edge_type): int64   // nr=165
SysIofsEdgeRemove(from_lpid, to_lpid):          int64   // nr=166
SysIofsEdgeCount(from_lpid):                    int64   // nr=167
SysIofsEdgeGetAll(from_lpid, out_buf, max):     int64   // nr=168
SysIofsEdgeHas(from_lpid, to_lpid):             int64   // nr=169

> iofs mount 1
iofs: mounting disk_id=1 ... OK

> iofs alloc "NodeA"
iofs: allocated lpid=2
> iofs alloc "NodeB"
iofs: allocated lpid=3
> iofs alloc "NodeC"
iofs: allocated lpid=4

> iofs edge-add 2 3 1
iofs: edge 2 -> 3  type=1  added
> iofs edge-add 2 4 2
iofs: edge 2 -> 4  type=2  added
> iofs edge-add 2 3 3
iofs: edge 2 -> 3  type=3  added

> iofs edge-count 2
iofs: lpid=2  edges=3
> iofs edge-has 2 3
iofs: edge 2 -> 3  exists=1
> iofs edge-rm 2 3
iofs: edge 2 -> 3  removed

> iofs edge-list 2
  [0]  2 -> 4  type=2
  [1]  2 -> 3  type=3

WP06 implementiert vier Graph-Traversal-Algorithmen auf den IOFS-Kanten (WP05). Alle Funktionen sind iterativ (keine Rekursion) und arbeiten mit pre-allozieren Puffern fixer Größe.

con IOFS_VISITED_BYTES: int64 := 8192;   // ceil(65536 / 8) — 1 Bit pro LPID
con TRAV_QUEUE_MAX:     int64 := 4096;   // max. Einträge im BFS-Queue / DFS-Stack
con SP_PARENT_BYTES:    int64 := 131072; // 65536 × 2 Bytes — uint16-Parent-Array (ShortestPath)
con SP_SENTINEL:        int64 := 65535;  // Markiert den BFS-Startknoten im Parent-Array

Jede Traversal-Funktion alloziert ihre Arbeitspuffer per mmap und gibt sie nach Abschluss frei:

BFS / DFS:
  visited  — 8 192 Bytes  (1 Bit / LPID, 65 536 LPIDs)
  queue / stack — max. TRAV_QUEUE_MAX × 8 Bytes = 32 KB

ShortestPath:
  parent   — 131 072 Bytes (65 536 × uint16, 0=unbesucht, 65535=Startknoten)
  queue    — 32 KB

Kein globaler Traversal-Zustand — jeder Aufruf ist vollständig re-entrant.

SysIofsBfs(start_lpid, out_buf, max_nodes):                  int64  // nr=170
SysIofsDfs(start_lpid, out_buf, max_nodes):                  int64  // nr=171
SysIofsReachable(from_lpid, to_lpid):                        int64  // nr=172
SysIofsShortestPath(from_lpid, to_lpid, path_buf, max_len):  int64  // nr=173

> iofs mount 1
iofs: mounting disk_id=1 ... OK

> iofs bfs 1
iofs bfs lpid=1  visited=4:
  1
  3
  4
  5

> iofs reachable 1 5
iofs: 1 -> 5  reachable=YES

> iofs path 1 5
iofs path (3 hops):
1 -> 3 -> 5

WP07 ergänzt einen String-zu-LPID-Namensraum auf der reservierten LPID=2. Namen sind bis zu 55 Bytes lang; pro Name-Store-Page passen 63 Einträge.

pub con IOFS_NS_LPID:             int64 := 2;   // well-known LPID für den Name Store
pub con IOFS_NS_ENTRY_SIZE:       int64 := 64;
pub con IOFS_NS_MAX_NAME:         int64 := 55;
pub con IOFS_NS_ENTRIES_PER_PAGE: int64 := 63;  // (4096 − 64) / 64
pub con IOFS_NS_OUT_ENTRY:        int64 := 80;

LPID-Reservierung: Nach IofsNameInit() sind LPID 1 (Root) und LPID 2 (Name Store) belegt. Neue Allokationen via IofsAllocLpidSlot() starten ab LPID 3.

Name-Store-Pages haben type = IOFS_TYPE_NAME_STORE (5). Das cont_lpid-Feld (Offset 0x18) zeigt auf die nächste Name-Store-Page in der Kette (0 = letzte Page).

Standard LYX!-Header (0x00–0x3F):
  0x04        IOFS_TYPE_NAME_STORE (5)
  0x08        LPID dieser Page
  0x12–0x13   entry_count (uint16 LE)
  0x18        next_name_page_lpid (int64, 0 = letzte Page)

Payload ab 0x40: entry_count × 64 Bytes je Eintrag:
  +0  lpid      (int64 LE)   — gebundener LPID
  +8  name_len  (uint8)      — Namenslänge in Bytes (1–55)
  +9  name      (bis 55 Bytes, kein Null-Terminator gespeichert)

+0   lpid      (int64)   — gebundener LPID
+8   name_len  (int64)   — Namenslänge (uint8, zero-extended)
+16  name      (bis 56 Bytes inkl. Null-Terminator)

SysIofsNameInit():                               int64  // nr=174
SysIofsNameLookup(name: pchar, name_len):        int64  // nr=175; Rückgabe = LPID oder 0
SysIofsNameBind(name: pchar, name_len, lpid):    int64  // nr=176
SysIofsNameUnbind(name: pchar, name_len):        int64  // nr=177
SysIofsNameList(out_buf, max_entries):           int64  // nr=178

> iofs mount 1
iofs: mounting disk_id=1 ... OK

> iofs name-init
iofs name-init: OK

> iofs name-bind system 1
iofs: 'system' -> lpid=1 bound

> iofs name-bind config 3
iofs: 'config' -> lpid=3 bound

> iofs name-lookup config
iofs: name='config'  lpid=3

> iofs name-list
  lpid=1  'system'
  lpid=3  'config'

> iofs name-unbind config
iofs: 'config' unbound

FAT32 bleibt das aktive sys_open/sys_read/sys_write-Backend. IOFS ist direkt über die Syscalls 155–164 erreichbar — als eigenständige Page-Store-Engine, noch nicht als VFS-Dateisystem.

Ring-3-Anwendungen
        │
        ├─ sys_open / sys_read / sys_write → VFS → FAT32  (aktives VFS-Backend)
        │
        └─ Syscalls 155–178 direkt → IOFS (Page-Store-Engine, kein VFS-Layer)
             mkfs_iofs / iofs mount / iofs alloc / iofs read / iofs write / iofs checkpoint
             iofs edge-* / iofs bfs / iofs dfs / iofs path / iofs name-*

IOFS ist ab WP02 als eigenständige Page-Store-Engine nutzbar. Der VFS-Mount-Layer (sys_open auf IOFS-Volumes) folgt in M5.

Letzte Aktualisierung: 2026-06-20