QRV — ein auf QNX Neutrino basierendes Betriebssystem, neu konzipiert für 64-Bit RISC-V

QRV ist eine grundlegende Adaption und Neuimplementierung des QNX Neutrino 6.4 Betriebssystems für moderne 64-Bit-Hardware, mit RISC-V (rv64g) als primärer Architektur und x86-64 als sekundärem Ziel. Das Projekt begann am Heiligabend 2020. Der Name QRV vermeidet bewusst jede Assoziation mit der Marke QNX.

QRV ist ein vollständiges Betriebssystem, nicht nur ein Kernel. Der Mikrokernel ist sein Herz – aber der größere Teil der Arbeit steckt in allem, was ihn umgibt. Am bemerkenswertesten ist taskman, der Prozess-/Speicher-/Pfad-Manager im Benutzermodus (QNXs procnto), der grundlegend überarbeitet und aus dem Kernel in den Benutzerbereich verlagert wurde; daneben wurden die C-Bibliothek, die Gerätetreiber, das Dateisystem, der dynamische Lader und die System-Server alle portiert, 64-Bit-sauber gemacht und an vielen Stellen wesentlich neu geschrieben. Der Mikrokernel ist bewusst klein; das Betriebssystem darum herum ist der Ort, an dem der Großteil von QRV lebt.

Dies ist kein Fork, der lediglich alten Code mit einem neuen Compiler übersetzt. Es ist eine sorgfältige, modulweise Portierung auf ein echtes LP64-Modell, bei der die proprietäre procnto-Grenze abgebaut, die IFS/Startup-Mechanik ersetzt und – seit den neuesten Versionen – der Big Kernel Lock des Kernels vollständig entfernt und der Prozess-/Speicher-/Pfad-Manager aus dem Kernel in einen Benutzermodus-Server ausgelagert wurde.

Diese README beschreibt QRV v0.43.

Der Entwicklungsblog mit der vollständigen Geschichte der Portierung ist unter https://r-tty.blogspot.com. Eine buchlange Erzählung, The QRV Porting Story, befindet sich im Quellbaum unter doc/tex/PortingStory/.

QRV wurde in enger Zusammenarbeit mit Claude Code, Anthropics agentischem Codierungstool, entwickelt – ein Großteil der Portierung, des SMP-Debuggings und der Dokumentation (einschließlich dieser README) wurde als Mensch-KI-Paarprogrammierung gemeinsam mit dem Autor durchgeführt.

Inhaltsverzeichnis

1. Was ist QRV
2. Lizenzierung
3. Beziehen der Quellen: obtain_proj.sh und der os/-Baum
4. Systemarchitektur
5. Taskman und der privilegierte Systemaufruf TM_PRIV
6. Der Big Kernel Lock – und seine Entfernung
7. Speicher: devb-nvme und fs-qrv
8. Benutzerbereich
9. Bauen und Ausführen
10. Ausführen auf echter Hardware
11. Schlussbemerkungen: Warum ein freier Klon wichtig ist

1. Was ist QRV

QNX ist ein Mikrokernel-Echtzeitbetriebssystem, dessen bestimmende Idee der synchrone Nachrichtenaustausch ist. In QNX ist der Kernel selbst winzig – er weiß, wie man Threads plant, Nachrichten übermittelt, Signale zustellt, Timer und Interrupts behandelt, und wenig anderes. Alles, was ein monolithisches OS innerhalb des Kernels unterbringen würde – der Prozessmanager, der Speichermanager, das Dateisystem, die Gerätetreiber, der Netzwerkstack – läuft in gewöhnlichen Benutzerprozessen, den sogenannten Ressourcen-Managern, und sie kommunizieren miteinander und mit ihren Clients über dasselbe Senden / Empfangen / Antworten-IPC-Primitiv.

Diese Architektur macht QNX elegant, und genau das bewahrt QRV. Ein Programm, das eine Datei öffnen möchte, sendet eine Nachricht; der Dateisystem-Server empfängt sie, erledigt die Arbeit und antwortet. Der Kernel vermittelt nur das Rendezvous. Das Ergebnis ist ein System, in dem ein Treiber abstürzen und neu gestartet werden kann, ohne den Kernel mitzureißen, in dem die vertrauenswürdige Codebasis in zehntausenden von Bytes gemessen wird und in dem die Grenze zwischen „Kernel" und „Anwendung" eine Nachricht ist, keine Privilegienwand voller Systemaufrufe.

QRV nimmt die QNX Neutrino 6.4 Community-Quellen aus der Zeit um 2009 und bringt dieses Design weiter:

• 64-Bit-sauber (LP64). Jeder Zeiger und jeder Größentyp ist 64-Bit; die Portierung jagt die int/uint32_t/pid_t-auf-Zeiger-Kürzungen, von denen 32-Bit-Code wimmelt.
• RISC-V zuerst. Das primäre Ziel ist qemu-system-riscv64 (die virt-Maschine) und das SiFive Unmatched (FU740)-Entwicklungsboard. x86-64 wird als Portierbarkeitscheck am Laufen gehalten.
• Keine proprietären Grenzen. Es gibt kein IFS und kein mkifs (QRV verwendet stattdessen das Standard CPIO-Format); es gibt keine separate Startup/Kernel-Trennung (Startup ist direkt mit dem Kernel gelinkt); es gibt keine Callouts und keine Mini-Treiber.
• Ein moderner Build. Eine Linux-artige Kconfig-Konfiguration, eine inkrementelle Kernel-Linkierung (Module werden nacheinander hinzugefügt und getestet, nicht als 32→64-Monolith dem Linker vorgeworfen) und eine Cross-Compiler-Toolchain (riscv64-linux-gnu-gcc).
• Ein umbenanntes, entmarkenrechtlichtes Vokabular. procnto ist durchgängig taskman (der Task Manager); alle „Neutrino"-Verweise sind getilgt.

QRV implementiert kein fork() (Programme starten über posix_spawn()), und es hat kein Demand Paging und keinen Swap – dieselben Entscheidungen, die QNX selbst in seiner 8.0-Generation getroffen hat.

2. Lizenzierung

QRV unterliegt zwei Lizenzen gleichzeitig, und zu verstehen, welche welche ist, ist unerlässlich, bevor Sie etwas bauen oder weitergeben.

• QRVs eigener Code ist Apache License 2.0. Alles, was für dieses Projekt von Grund auf neu geschrieben wurde – die RISC-V-Portierung, das neue Build-System, die Aufteilung des Taskman im Benutzermodus, die lock-freie Kernel-Überarbeitung, die von uns verfassten Treiber und Werkzeuge – ist Apache 2.0. Der vollständige Text steht in LICENSE.txt.

• QNX-abgeleiteter Code unterliegt der BlackBerry QNX Community License (QCL) 2.0. Die Teile von QRV, die von den QNX Neutrino Community-Quellen von 2009 abstammen, bleiben unter der QCL, die die nicht-kommerzielle und akademische Nutzung der abgeleiteten Quellen erlaubt. QRV kann QNX-Code nicht und wird ihn nicht umlizenzieren.

Diese Dual-Lizenz-Realität ist genau der Grund, warum dieses Repository keinen baufertigen Quellbaum enthält. Wir dürfen die QNX-abgeleiteten Quellen nicht weitergeben. Statt den Code auszuliefern, liefert dieses Repository ein Rezept (siehe nächster Abschnitt): eine Karte, wohin jede QNX-Datei gehört, plus die QRV-Patches, die sie transformieren. Sie besorgen sich die QNX-Community-Quellen selbst von ihrem öffentlichen Spiegel, und das Rezept rekonstruiert den QRV-Baum auf Ihrem Rechner. Ihre Kopie gehört Ihnen; wir geben nur unsere eigenen Apache-lizenzierten Patches und Metadaten weiter.

QRV enthält auch Code unter anderen freizügigen Lizenzen – zum Beispiel BSD-lizenzierte Komponenten, die von FreeBSD übernommen wurden (als Ersatz für gealterte QNX-Module), einen MIT-lizenzierten Virtio-Blocktreiber mit xv6-Abstammung und die MirBSD Korn Shell (mksh) als System-Shell. WHAT_IS_WHAT.md ist die maßgebliche, komponentenweise Aufschlüsselung, was unter welcher Lizenz steht und woher es stammt – konsultieren Sie sie immer, wenn Sie sich über eine bestimmte Datei oder ein Subsystem unsicher sind.

Schließlich enthält das Repository PETITION.md: eine offene Anfrage an QNX Software Systems und BlackBerry, die historischen Neutrino-Quellen von 2007–2009 unter eine freizügige OSI-zugelassene Lizenz zu stellen. Wenn Sie möchten, dass die Grundlagen dieser Arbeit eines Tages vollständig frei sind, ist dieses Dokument der Ort, um Ihren Namen hinzuzufügen.

3. Beziehen der Quellen: obtain_proj.sh und der os/-Baum

Da die QNX-abgeleiteten Quellen hier nicht weitergegeben werden können, ist dieses Repository eine Quell-Rekonstruktionsdistribution. Es enthält:

Was das Skript tut```

$ ./obtain_proj.sh

1. **Klont das Upstream-QNX-Community-Mirror** (`github.com/vocho/openqnx`,
   ein flacher Klon).
2. **Platziert Dateien** gemäß `placement.txt`, indem jede Upstream-Datei
   in ihren QRV-Speicherort unter `os/` kopiert wird. Es wird gemeldet, wie viele Dateien
   platziert, bereits vorhanden oder fehlend sind.
3. **Entfernt den Klon**, sobald die Platzierung abgeschlossen ist.
4. **Wendet die QRV-Patch-Serie** aus `patches/series` in der richtigen Reihenfolge an. Jeder
   Patch ist LZ4-komprimiert (`*.patch.lz4`) und wird mit
   `lz4cat … | patch -p1` angewendet. Die Patches tragen die Version des aktuellen
   Releases.
5. **Setzt ausführbare Berechtigungen** für die wenigen Skripte, die diese benötigen
   (z.B. `emu.sh`, `host_tools/mkgpt.py`).

Die erforderlichen Werkzeuge sind `git`, `patch` und `lz4cat` (aus dem `lz4`-
Paket); das Skript prüft sie vorab und teilt mit, wie fehlende installiert werden können.

Das Endergebnis ist **`os/`** — ein vollständiger, baubarer QRV-Quellbaum:```
os/
├── kernel/          Everything linked into the qrv-kernel binary
│   ├── arch/riscv/     RISC-V port: vectors, traps, SBI, context switch,
│   │   ├── startup/        arch-specific startup (head.S, mmu.c, …)
│   │   ├── platform/       qemu_virt/, unmatched/
│   │   └── include/        context.h, cpu_paging.h, sbi.h, …
│   ├── startup/         arch-independent startup (hardware_init, smp, …)
│   ├── nano/            core nanokernel: messaging, scheduling, sync, xfer
│   ├── kext/            kernel extensions (kerexts)
│   └── include/         kernel-internal headers
├── taskman/         The Task Manager (QNX's "procnto"), a user-mode server
│   ├── sys/            system manager: main, ELF loader, support
│   ├── proc/           process manager: spawn, wait, …
│   ├── mem/            memory manager: page tables, physical allocator
│   │   └── pageman/        page-granularity virtual-memory operations
│   └── path/           path manager: namespace, /dev/*, /proc/*
├── lib/             C library and runtime
├── include/         User-space-visible headers (the public ABI)
├── userland/        Shell, utilities, drivers, servers (resource managers)
├── servers/         pci, slogger
├── dev/             Device drivers (virtio block, 8250 UART, …)
├── boot/            Boot artifacts and deploy helpers
├── host_tools/      Host-side tooling (mkgpt.py, …)
├── doc/             Documentation, incl. The QRV Porting Story (LaTeX)
├── Kconfig, Makefile, def.mk, common.mk, emu.sh

From there, cd os && make builds the system (see §9).

4. Systemarchitektur

QRV ist ein echtes Mikrokernsystem. Der Privileg-Stack, von der Hardware aufwärts, sieht auf RISC‑V wie folgt aus:``` ┌───────────────────────────────────────────────────────────────────────┐ │ User space (U-mode) │ │ │ │ sh pidin lspci sloginfo login ... │ │ │ │ │ │ │ │ │ devb-nvme fs-qrv devc-ser* pci slogger ← resource managers │ │ │ │ │ │ │ │ │ │ └──────┴───────┴────────┴─────────┴───────┘ │ │ │ libc (send / receive / reply stubs) │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ taskman — process · memory · path manager │ │ │ │ a U-mode server, privileged via TM_PRIV │ │ │ └─────────────────────────────────────────────────────────────────┘ │ └────────────────────────────────────│──────────────────────────────────┘ │ ecall (syscall / message) ┌───────────────────────────────────────────────────────────────────────┐ │ QRV microkernel (S-mode) │ │ │ │ message passing · channels & connections · scheduling · │ │ threads · synchronization · signals · timers & clocks · │ │ interrupts · syscall dispatch · TM_PRIV kernel extensions │ └───────────────────────────────────────│───────────────────────────────┘ │ SBI ecall ┌───────────────────────────────────────────────────────────────────────┐ │ OpenSBI firmware (M-mode) │ └───────────────────────────────────────│───────────────────────────────┘ │ ┌───────────────────────────────────────────────────────────────────────┐ │ RISC-V 64-bit hardware — QEMU virt · SiFive Unmatched U740 │ └───────────────────────────────────────────────────────────────────────┘

**Der Kernel (S-Modus)** ist die einzige Komponente, die im klassischen Sinne privilegiert läuft. Seine Subsysteme sind klein und fokussiert:

- **Nachrichtenübermittlung** — `ker_message.c`, `ker_fastmsg.c`, `nano_message.c`
- **Kanäle & Verbindungen** — `ker_channel.c`, `ker_connect.c`
- **Threads & Scheduling** — `ker_thread.c`, `ker_sched.c`, `nano_sched.c`
- **Synchronisation** — `ker_sync.c`, `nano_sync.c`
- **Signale** — `ker_signal.c`
- **Timer & Uhren** — `ker_timer.c`, `ker_clock.c`
- **Interrupts** — `ker_interrupt.c`
- **Syscall-Dispatch** — `ker_call_table.c`
- **Datentransfer** — die `nano_xfer*.c`-Familie (die Adressraum-übergreifende Kopier-Engine, die Nachrichten-Nutzlasten sicher zwischen Prozessen bewegt)

Die Schnittstelle zwischen dem Bootstrapper und dem Kernel ist die **Syspage** (`include/sys/syspage.h`); der pro-CPU-Zustand lebt in der **Cpupage**; der vollständige Registerkontext ist `RISCV_CPU_REGISTERS`. Auf RISC-V wird jede „CPU" überall durch ihre **Hart-ID** identifiziert – es gibt einen einzigen, durchgängigen CPU-Benennungs-Namensraum.

**Alles andere ist ein Benutzerprozess.** Der Prozess-/Speicher-/Pfad-Manager, die Block- und seriellen Treiber, das Dateisystem, der PCI-Server, der System-Logger – alles Ressourcen-Manager, die durch Senden einer Nachricht erreicht werden. Der Kernel enthält kein Dateisystem; er enthält die Fähigkeit für einen Prozess, einen anderen zu bitten, *ein* Dateisystem zu sein.

---

## 5. Taskman und der privilegierte Syscall `TM_PRIV`

**`taskman`** ist QRVs Bezeichnung für das, was QNX `procnto` nannte: den kombinierten **Prozess-Manager, Speicher-Manager und Pfad-(Namensraum-)Manager**. In einem klassischen QNX-System ist dieser Code in das Kernel-Image eingebunden. Eine der größeren strukturellen Errungenschaften von QRV ist, dass **taskman nun im Benutzermodus läuft** – es ist ein gewöhnlicher U-Modus-Prozess, nicht Teil des privilegierten Kernels.

Das wirft eine offensichtliche Frage auf: Wenn taskman im Benutzerraum lebt, wie erledigt es dann die zutiefst privilegierten Dinge, die ein Prozess- und Speicher-Manager tun muss – Seitentabellen manipulieren, physischen RAM zuweisen, Adressräume erstellen und zerstören, Signale und Pulse zustellen, Prozesse abbauen?

Die Antwort ist ein einziger, streng kontrollierter Zugang: **`__KER_TM_PRIV`**, Syscall-Slot 2. Es ist die *einzige* Tür, durch die taskman auf kernelprivilegierte Operationen zugreift, und hinter diesem einen Slot sitzt eine Dispatch-Tabelle mit **~98 Unteroperationen** – kleine **Kernel-Erweiterungen** ("Kerexts"), die jeweils eine klar definierte privilegierte Aktion ausführen und zurückkehren. Einige repräsentative Familien:

- **Prozess-Lebenszyklus** — `PROCESS_CREATE`, `PROCESS_EXEC`, `PROCESS_DESTROY`, `PROCESS_STARTUP`, `PROCESS_SHUTDOWN`, `REPARENT`
- **Physischer & virtueller Speicher** — `PA_ALLOC`, `PA_FREE`, `PA_QUANTUM_TO_PADDR`, `PAGE_CONT`, `STACK_CONT`, `ASPACE_MEMCPY`
- **Berechtigungen & Limits** — `CRED_GET`, `CRED_SET`, `LIMITS_GET/SET`
- **Zustellung & Objekte** — `PULSE_DELIVER`, `SIGNAL_DELIVER`, `QUERY_OBJECT`, `CHANNEL_DESTROY`, `CONNECT_DETACH`
- **SMP & Plattform** — `SMP_BRINGUP`, `LEGAL_CPU_MASK`, `GET_KERN_PGDIR`, `ICACHE_SYNC` (die RISC-V-Befehlscache-Kohärenzoperation, neu in v0.43)

Dieses Design hält die **vertrauenswürdige Rechenbasis klein** – der eigentliche Kernel bleibt minimal – und gibt taskman genau die privilegierten Primitive, die es braucht, und **nichts weiter**. Entscheidend ist, dass der Kernel-Heap und andere Kernel-Interna für den U-Modus unzugänglich bleiben (Kernel-Seiten behalten `PTE_U=0`); taskman erledigt seine Arbeit durch Copy-in/Copy-out-Kerexts, nie durch die Übergabe eines rohen Kernel-Zeigers. Das Enum lebt in `kernel/include/ker+tm/tm_kercalls.h`; die Dispatch-Tabelle in `kernel/ker_tm_priv.c`.

---

## 6. Die große Kernel-Sperre – und ihre Entfernung

Frühes QRV – ähnlich wie die QNX-Generation, von der es auf Multiprozessorsystemen abstammte – schützte den Kernel mit einer einzigen **großen Kernel-Sperre (Big Kernel Lock, BKL)**: einem globalen `inkernel`-Wort, das genau einen Hart gleichzeitig in den Kernel ließ. Egal wie viele CPUs liefen, jeder Systemaufruf und jede taskman-Nachricht serialisierten durch diese eine Sperre. Korrekt, einfach – und eine harte Obergrenze für die SMP-Skalierbarkeit.

**Seit v0.42 ist die BKL weg.** Dies war die Hauptschlagzeile einer langen Reihe von Release Candidates und das Thema der Kapitel 9–14 von *The QRV Porting Story*. Systemaufrufe und taskman-Nachrichten laufen jetzt **gleichzeitig über Harts hinweg** unter feinkörnigen, pro-Objekt-Sperren:

- **Pro-Objekt-Sperrung.** Eine Sperre pro `tChannel` und pro `tConnect` schützt die Nachrichtenwarteschlangen; eine `vec_slock` pro Prozess schützt den Thread-Vektor; eine `sched_slock` pro Dispatch schützt die Run-Queues; eine `alloc_slock` schützt den Kernel-Heap.
- **Sperrfreie Nachrichtenübermittlung.** `MsgSend` / `MsgReceive` / `MsgReply` und die `Sync*`-Familie nehmen **überhaupt keine globale Sperre**. Das Hart-übergreifende Rendezvous wird durch pro-Thread-Bridge-Bits und Hardware-Speicherbarrieren koordiniert, nicht durch gegenseitigen Ausschluss.
- **SMR (RCU-äquivalente) Freigabe.** Threads, Verbindungen und Kanäle werden durch Safe-Memory-Reclamation ausgemustert, sodass sperrfreie Lookups niemals auf ein freigegebenes Objekt dereferenzieren.

Auf QEMU `virt` mit `-smp 8` bootet der Kernel zuverlässig bis zur `login:`-Eingabeaufforderung und hält einer 300-Iterationen-`pidin`-Stressschleife ohne Blockaden stand.

---

## 7. Speicher: `devb-nvme` und `fs-qrv`

Getreu dem Mikrokernel-Modell ist der Speicher in QRV **zwei zusammenarbeitende Benutzerprozesse**, kein Kernel-Subsystem:

- **`devb-nvme`** – der Blockgerätetreiber. Er spricht NVMe über PCIe (mit integrierter GPT-Partitionsanalyse), findet den Controller über den PCI-Server und stellt Blockgeräte wie `/dev/nvme0n1` und dessen Partitionen bereit. (Ein `devb-virtio`-Gegenstück treibt das QEMU-virtio-blk-Gerät für das emulierte Ziel an.)
- **`fs-qrv`** – der Dateisystem-Ressourcenmanager. Er mountet eine Partition und bedient den POSIX-Dateisystem-Namensraum über Nachrichtenübermittlung: Das `open`/`read`/`write`/`close` einer Anwendung wird zu Nachrichten, die `fs-qrv` beantwortet.

Ein typisches Hochfahren mountet eine echte NVMe-Partition und führt darauf Programme aus:```
mount -t qrv /dev/nvme0n1p5 /disk2

Dieser Pfad – Blocktreiber, Partitionierung, Dateisystem-Server und der Kernel, der jede Nachricht zwischen ihnen vermittelt – läuft durchgängig sowohl auf QEMU als auch auf dem NVMe-Laufwerk des SiFive Unmatched.

8. Benutzerbereich

QRV startet über sysinit/init, bringt den seriellen Konsolentreiber (devc-ser8250 auf QEMU, devc-sersifive auf dem FU740), den PCI-Server, den Storage-Stack und getty/login hoch und landet Sie an einer Shell-Eingabeaufforderung. Die wichtigsten Benutzerbereichsprogramme:

• sh — mksh, die MirBSD Korn Shell. Eine echte, skriptfähige POSIX-Shell ist die System-Shell; Boot-Skripte (level1.sh, …) sind gewöhnliche Shell-Skripte.
• pidin — das klassische QNX-Werkzeug für Prozessinformationen: listet Prozesse, Threads, deren Zustände, Speicher und mehr auf. Es ist QRVs primäre „Lebt das System noch?“-Sonde und seine Standard-Stresstest-Last.
• lspci — zählt den PCI/PCIe-Bus über den PCI-Server auf.
• sloginfo — gibt das vom slogger-Server gesammelte Systemprotokoll aus.

Daneben gibt es die Bausteine eines nutzbaren Mehrbenutzersystems: getty und login (mit Anmelde-/Authentifizierungsunterstützung), mount, shutdown, pipe und Kernprogramme (ls, cat, …). Jedes QRV-Programm ist multithreaded – mindestens ein Hauptthread und ein Systemthread –, weshalb korrekte SMP-Synchronisation (siehe §6) so wichtig ist.

9. Bauen und Ausführen

Toolchain```

Cross-compiler : riscv64-linux-gnu-gcc CPU flags : -march=rv64g -mcmodel=medany -mno-relax Build style : -nostdinc -nostdlib -ffreestanding

### Häufige Befehle (ausführen in `os/`)```bash
make                 # Build everything: startup + kernel + module package
make -Bj             # Force a full parallel rebuild (do this after header changes)
make startup         # Build startup only
make kernel          # Build kernel only
make modpkg          # Create the module package (CPIO)
make qemu            # Build and run in QEMU
./emu.sh             # Run in QEMU (4 CPUs, 256M RAM, virt machine)
./emu.sh -P 1        # Run with a single hart
./emu.sh -gdb        # Run with the GDB remote stub (port 1234)

10. Ausführen auf echter Hardware

QRVs zweites, aber ernstzunehmendes Ziel ist das SiFive Unmatched (FU740) – eine echte RISC-V-Workstation-Platine. Dass ein Mikrokernel, der sauber auf QEMU bootet, auch auf echter Hardware sauber bootet, förderte eine Klasse von Fehlern zutage, die Emulation einfach nicht zeigt, und deren Verfolgung macht einen Großteil der neueren Veröffentlichungen aus.

Das Paradebeispiel, behoben in v0.43: Zwei Monate lang lief QRV einwandfrei auf QEMU und stürzte auf echter Hardware ab. Auf dem FU740 stürzte jedes Programm – pidin, lspci, was auch immer – nach ein paar Spawns ab, jeder Absturz anders als der vorherige, der Programmzeiger wanderte ins Nichts. Die Ursache war nicht etwa Speicherkorruption, sondern Instruktionscache-Inkohärenz: RISC-V garantiert keine Kohärenz zwischen Datenspeicherungen und Instruktionsabruf, daher ist frisch geladener Programmcode für die Abrufeinheit eines Harts unsichtbar, bis dieses Hart fence.i ausführt – und Code, der auf einem anderen Hart als dem, der ihn geladen hat, ausgeführt werden soll, benötigt dort ein entferntes fence.i. QRVs Lader tat keines von beidem (er berechnete sogar ein "I-Cache ungültig machen"-Flag und warf es dann weg). QEMU modelliert keinen Instruktionscache, daher war der Fehler dort unsichtbar und auf dem U74 deterministisch.

Der Fix – ein lokales plus SBI-übergreifendes fence.i (cpu_icache_sync_all()) an jeder Stelle, an der eine Seite ausführbar wird – verwandelte eine Spawn-Schleife, die alle paar Durchläufe abstürzte, in eine, die auf dem FU740 über 600 aufeinanderfolgende Spawns sauber durchlief. Die vollständige Untersuchung, einschließlich der zuerst aufgestellten falschen Hypothese und der Diagnose, die sie widerlegte, ist der abschließende Abschnitt von Kapitel 14 von The QRV Porting Story.

Die bisher erreichten Hardware-Meilensteine umfassen das Booten bis zu einem login:-Prompt im Benutzermodus-Taskman auf dem FU740 und das Einbinden und Ausführen von Testprogrammen von einer echten NVMe-Partition.

11. Schlussbemerkungen: Warum ein freier Klon wichtig ist

QNX ist eines der einflussreichsten Mikrokernel-Designs, das je ausgeliefert wurde. Sein Senden/Empfangen/Antworten-Modell hat Generationen von Systemingenieuren gelehrt, wie eine saubere OS-Architektur aussehen kann. Und doch hat der Code, der es verkörpert, mehr als ein Jahrzehnt in einer eigenartigen Schwebe verbracht: sichtbar genug, um unter einer Community-Lizenz studiert zu werden, aber nicht frei genug, um weitergegeben, weiterentwickelt oder ein lebendiges Ökosystem darum herum aufzubauen. Ein so gutes Design verdient etwas Besseres, als nur als schreibgeschütztes Artefakt erhalten zu werden.

Das ist der Grund, warum diese Arbeit existiert. QRV ist, ehrlich gesagt, ein Übergangsfahrzeug – ein Weg, die Architektur tiefgehend zu erlernen, indem man sie portiert, auseinandernimmt und auf neuer Hardware wieder zusammensetzt, indem man den Kernel-Sperre entfernt und den Prozessmanager in den Benutzermodus hebt und genau herausfindet, welche Annahmen tragend waren. Jeder auf echter Hardware verfolgte Fehler, jedes neu geschriebene Subsystem, das 64-Bit-sauber ist, jede abgebaute proprietäre Grenze ist Wissen, das eine wirklich freie Implementierung benötigen wird.

Denn das langfristige Ziel ist nicht, für immer eine gepatchte Kopie fremder Quellen zu pflegen. Es ist ein vollständig freies, von Grund auf neu entwickeltes Betriebssystem, das mit den Schnittstellen von QNX kompatibel und seiner Mikrokernel-Philosophie treu ist, aber nichts proprietärem Code schuldet – eines, das ohne Erlaubnis verwendet, gelehrt, ausgeliefert und verbessert werden kann. QRV ist der Weg, wie wir beweisen, dass ein solches System nicht nur möglich, sondern praktisch ist, und wie wir die Erfahrung sammeln, es richtig zu bauen.

Wenn Sie möchten, dass die historischen Grundlagen selbst frei werden, fügen Sie Ihren Namen zu PETITION.md hinzu. Und wenn Sie sehen möchten, wie ein moderner, ehrlich entwickelter Mikrokernel von innen aussieht – klonen Sie das Rezept, führen Sie obtain_proj.sh aus und lesen Sie den Code.

QRV – Anpassung und Neuimplementierung von QNX Neutrino 6.4 für 64-Bit-Hardware. Gestartet am Heiligabend 2020. Apache 2.0 (QRVs eigener Code) + BlackBerry QCL 2.0 (QNX-abgeleitete Quellen). Siehe WHAT_IS_WHAT.md für die komponentenweise Aufschlüsselung.