QRVは、現代の64ビットハードウェア向けに、QNX Neutrino 6.4オペレーティングシステムを根本から適応・再実装したものです。主要アーキテクチャはRISC-V（rv64g）、セカンダリターゲットはx86-64です。プロジェクトは2020年のクリスマスイブに始まりました。QRVという名称は、QNXの商標との関連を意図的に避けています。
QRVは、カーネルだけでなく完全なオペレーティングシステムです。マイクロカーネルがその心臓部ですが、作業の大部分はそれを取り巻くすべてのものに費やされています。最も注目すべきは、ユーザーモードのプロセス/メモリ/パスマネージャ（QNXのprocnto）であるtaskmanです。これは大幅に再加工され、カーネルからユーザースペースに引き上げられました。それに加えて、Cライブラリ、デバイスドライバ、ファイルシステム、動的ローダー、システムサーバーがすべて移植され、64ビット対応になり、多くの場所で大幅に書き直されています。マイクロカーネルは設計上小さいままですが、その周りのオペレーティングシステムがQRVの大部分を占めています。
これは、古いコードを新しいコンパイラで単にコンパイルするフォークではありません。これは、モジュールごとに慎重に真のLP64モデルに移植したものであり、独自のprocnto境界を解体し、IFS/スタートアップ機構を置き換え、最新リリースではカーネルのBig Kernel Lockを完全に削除し、プロセス/メモリ/パスマネージャをカーネルからユーザーモードサーバーに移動させています。
このREADMEはQRV v0.43について説明しています。
開発ブログ（移植の全容）は https://r-tty.blogspot.com にあります。本格的な文書『QRV移植物語』は、ソースツリーの doc/tex/PortingStory/ にあります。
QRVはClaude Code（Anthropicのエージェント型コーディングツール）と密接に協力して開発されました。移植作業、SMPデバッグ、ドキュメント（このREADMEを含む）の多くは、人間とAIのペアプログラミングの取り組みとして、著者とともに行われました。
obtain_proj.sh と os/ ツリーTM_PRIV特権システムコールdevb-nvme と fs-qrvQNXはマイクロカーネルリアルタイムオペレーティングシステムであり、その中心的な考え方は同期メッセージパッシングです。QNXでは、カーネル自体は小さく、スレッドのスケジューリング、メッセージの受け渡し、シグナルの配信、タイマーと割り込みの処理、そしてそれ以外はほとんど行いません。モノリシックOSがカーネル内部に入れるものすべて—プロセスマネージャ、メモリマネージャ、ファイルシステム、デバイスドライバ、ネットワークスタック—は、リソースマネージャと呼ばれる通常のユーザープロセスとして実行され、同じsend / receive / reply IPCプリミティブを通じて互いに、そしてクライアントと通信します。
このアーキテクチャこそがQNXをエレガントにしており、QRVがまさに保存しているものです。ファイルを開きたいプログラムはメッセージを送信し、ファイルシステムサーバーがそれを受信し、処理を行い、応答します。カーネルはランデブーを仲介するだけです。その結果、ドライバがクラッシュしてもカーネルをダウンさせることなく再起動でき、信頼できるコンピューティングベースは数十キロバイトで測定され、「カーネル」と「アプリケーション」の境界は、システムコールだらけの特権壁ではなく、メッセージであるシステムが実現します。
QRVは2009年当時のQNX Neutrino 6.4コミュニティソースを基に、その設計を未来に引き継ぎます：
int/uint32_t/pid_tのポインタ上の切り捨てを追跡し修正します。qemu-system-riscv64（virtマシン）とSiFive Unmatched (FU740) 開発ボードです。x86-64は移植性確認用にビルドを維持しています。mkifsはありません（QRVは代わりに標準のCPIO形式を使用）。スタートアップ/カーネルの分離もなく（スタートアップはカーネルに直接リンク）、コールアウトやミニドライバもありません。Kconfig設定、インクリメンタルカーネルリンク（モジュールは32→64のモノリスとしてリンカに投げられるのではなく、一度に1つずつ追加・テスト）、クロスコンパイラツールチェーン（riscv64-linux-gnu-gcc）。procntoは全体で**taskman**（Task Manager）に変更。「Neutrino」への参照はすべて除去されています。QRVはfork()を実装しておらず（プログラムはposix_spawn()で起動）、デマンドページングやスワップもありません—これらはQNX自身が8.0世代で行ったのと同じ選択です。
QRVは同時に2つのライセンスが適用されます。どちらがどれかを理解することは、何かをビルドしたり再配布したりする前に不可欠です。
QRV独自のコードはApache License 2.0です。 このプロジェクトのためにゼロから書かれたものすべて—RISC-V移植、新しいビルドシステム、ユーザーモードtaskman分割、ロックフリーカーネル再加工、私たちが作成したドライバやツール—はApache 2.0です。全文は**LICENSE.txt**にあります。
QNX由来のコードはBlackBerry QNX Community License (QCL) 2.0です。 2009年のQNX Neutrinoコミュニティソースから派生したQRVの部分は引き続きQCLのもとで、派生ソースの非商用および学術目的での使用を許可します。QRVはQNXのコードのライセンスを変更することはできません。
このデュアルライセンスの現実こそが、このリポジトリにビルド可能なソースツリーが含まれていない理由です。 QNX由来のソースを再配布することは許可されていません。そのため、コードを提供する代わりに、このリポジトリはレシピ（次のセクション参照）を提供します。各QNXファイルの配置先と、それを変換するQRVパッチのマップです。あなた自身でアップストリームのQNXコミュニティソースを公開ミラーから入手し、レシピがあなたのマシン上でQRVツリーを再構築します。あなたのコピーはあなたのものです。私たちは、Apacheライセンスのパッチとメタデータのみを再配布します。
QRVはまた、他のパーミッシブライセンスのコードも取り入れています。例えば、FreeBSDから採用したBSDライセンスのコンポーネント（古いQNXモジュールを置き換え）、xv6由来のMITライセンスvirtioブロックドライバ、システムシェルとしてのMirBSD Kornシェル（mksh）などです。WHAT_IS_WHAT.mdが、何がどのライセンスでどこから来たのかの信頼できるコンポーネントごとの内訳です—特定のファイルやサブシステムについて不明な場合は、それを参照してください。
最後に、リポジトリには**PETITION.md**が含まれています。これは、QNX Software SystemsおよびBlackBerryに対して、歴史的な2007〜2009年のNeutrinoソースをパーミッシブなOSI承認ライセンスで再ライセンスするよう求める公開要請です。この作業の基盤がいつか完全に自由になることを望むなら、その文書にあなたの名前を追加してください。
obtain_proj.sh と os/ ツリーQNX由来のソースはここで再配布できないため、このリポジトリはソース再構築配布です。以下が含まれます：
$ ./obtain_proj.sh
1. **上流のQNXコミュニティミラーをクローンします** (`github.com/vocho/openqnx`、浅いクローン)。
2. `placement.txt`に従って**ファイルを配置**し、各上流ファイルを`os/`以下の適切なQRVの場所にコピーします。配置されたファイル、既に存在するファイル、不足しているファイルの数を報告します。
3. 配置が完了したら**クローンを削除**します。
4. `patches/series`から順に**QRVパッチシリーズを適用**します。各パッチはLZ4圧縮されており（`*.patch.lz4`）、`lz4cat … | patch -p1`で適用されます。パッチには現在のリリースのバージョンが含まれています。
5. 必要なスクリプト（例：`emu.sh`、`host_tools/mkgpt.py`）に**実行権限を設定**します。
必要なツールは`git`、`patch`、`lz4cat`（`lz4`パッケージから）です。スクリプトは事前にこれらを確認し、不足しているものがあればインストール方法を表示します。
最終成果物は**`os/`** — 完全でビルド可能なQRVソースツリーです。```
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
そこから、cd os && make でシステムがビルドされます（§9 を参照）。
QRVは真のマイクロカーネルシステムです。特権スタックは、メタルから上に向かって、RISC-Vでは次のようになります:``` ┌───────────────────────────────────────────────────────────────────────┐ │ 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 │ └───────────────────────────────────────────────────────────────────────┘
**The kernel (S-mode)** is the only component that runs privileged in the
classic sense. Its subsystems are small and focused:
- **Message passing** — `ker_message.c`, `ker_fastmsg.c`, `nano_message.c`
- **Channels & connections** — `ker_channel.c`, `ker_connect.c`
- **Threads & scheduling** — `ker_thread.c`, `ker_sched.c`, `nano_sched.c`
- **Synchronization** — `ker_sync.c`, `nano_sync.c`
- **Signals** — `ker_signal.c`
- **Timers & clocks** — `ker_timer.c`, `ker_clock.c`
- **Interrupts** — `ker_interrupt.c`
- **Syscall dispatch** — `ker_call_table.c`
- **Data transfer** — the `nano_xfer*.c` family (the cross-address-space
copy engine that moves message payloads safely between processes)
The interface between the bootstrapper and the kernel is the **syspage**
(`include/sys/syspage.h`); per-CPU state lives in the **cpupage**; the full
register context is `RISCV_CPU_REGISTERS`. On RISC-V, each "CPU" is
identified by its **hart ID** everywhere — there is a single CPU-naming
namespace, end to end.
**Everything else is a user process.** The process/memory/path manager,
the block and serial drivers, the filesystem, the PCI server, the system
logger — all of them are resource managers reached by sending a message.
The kernel does not contain a filesystem; it contains the ability for one
process to ask another to *be* a filesystem.
---
## 5. Taskman と `TM_PRIV` 特権システムコール
**`taskman`** は、QNXが `procnto` と呼んでいたものに対するQRVの名前です。それは、統合された **プロセスマネージャー、メモリマネージャー、およびパス（名前空間）マネージャー** です。古典的なQNXシステムでは、このコードはカーネルイメージに融合されています。QRVの大きな構造的成果の1つは、**taskmanが現在ユーザーモードで実行されている** ことです — それは通常のUモードプロセスであり、特権カーネルの一部ではありません。
これにより明らかな疑問が生じます：taskmanがユーザースペースに存在する場合、プロセスおよびメモリマネージャーが行わなければならない深く特権的な操作 — ページテーブルの操作、物理RAMの割り当て、アドレス空間の作成と破棄、シグナルとパルスの配信、プロセスの終了 — をどのように実行するのでしょうか？
その答えは、単一の厳密に制御されたゲートウェイです：**`__KER_TM_PRIV`**、システムコールスロット2です。これは、taskmanがカーネル特権操作にアクセスするための*唯一の*扉であり、その1つのスロットの背後には、**約98のサブオペレーション** のディスパッチテーブルがあります — それぞれが1つの明確に定義された特権アクションを実行して戻る小さな **カーネル拡張（"kerexts"）** です。いくつかの代表的なファミリー：
- **プロセスライフサイクル** — `PROCESS_CREATE`, `PROCESS_EXEC`,
`PROCESS_DESTROY`, `PROCESS_STARTUP`, `PROCESS_SHUTDOWN`, `REPARENT`
- **物理＆仮想メモリ** — `PA_ALLOC`, `PA_FREE`,
`PA_QUANTUM_TO_PADDR`, `PAGE_CONT`, `STACK_CONT`, `ASPACE_MEMCPY`
- **資格情報＆制限** — `CRED_GET`, `CRED_SET`, `LIMITS_GET/SET`
- **配信＆オブジェクト** — `PULSE_DELIVER`, `SIGNAL_DELIVER`,
`QUERY_OBJECT`, `CHANNEL_DESTROY`, `CONNECT_DETACH`
- **SMP＆プラットフォーム** — `SMP_BRINGUP`, `LEGAL_CPU_MASK`, `GET_KERN_PGDIR`,
`ICACHE_SYNC` (v0.43で新しく追加されたRISC-V命令キャッシュコヒーレンス操作)
この設計により、**信頼できるコンピューティングベースを小さく保ち**（実際のカーネルは最小限のまま）、taskmanに必要な特権プリミティブを**それ以上でもそれ以下でもなく**正確に提供します。重要なのは、カーネルヒープやその他のカーネル内部がUモードからアクセスできないままであることです（カーネルページは `PTE_U=0` を維持）。taskmanは、コピーイン/コピーアウトのkerextsを通じて作業を実行し、生のカーネルポインタを受け取ることはありません。enumは `kernel/include/ker+tm/tm_kercalls.h` にあります。ディスパッチテーブルは `kernel/ker_tm_priv.c` にあります。
---
## 6. ビッグカーネルロック — そしてその除去
初期のQRV — マルチプロセッサシステムにおける元となったQNX世代と同様に — カーネルを単一の **ビッグカーネルロック (BKL)** で保護していました：グローバルな `inkernel` ワードで、一度に正確に1つのhartだけをカーネルに入れることができました。CPUの数に関係なく、すべてのシステムコールとすべてのtaskmanメッセージはその1つのロックを通じてシリアル化されました。正確でシンプル — しかしSMPのスケーラビリティに対する厳しい上限でした。
**v0.42時点で、BKLはなくなりました。** これは一連のリリース候補の見出しであり、*The QRV Porting Story* の第9章から第14章の主題でした。システムコールとtaskmanメッセージは現在、**harts間で並行して実行** され、きめ細かいオブジェクトごとのロックの下で動作します：
- **オブジェクトごとのロック。** `tChannel` ごとのロックと `tConnect` ごとのロックがメッセージキューを保護します。プロセスごとの `vec_slock` がスレッドベクターを保護します。ディスパッチごとの `sched_slock` が実行キューを保護します。`alloc_slock` がカーネルヒープを保護します。
- **ロックフリーメッセージパッシング。** `MsgSend` / `MsgReceive` / `MsgReply` および `Sync*` ファミリーは **グローバルロックを一切取得しません**。hart間のランデブーは、相互排他ではなく、スレッドごとのブリッジビットとハードウェアメモリフェンスによって調整されます。
- **SMR（RCU相当）の再利用。** スレッド、接続、チャネルは安全なメモリ再利用（SMR）を通じて廃棄され、ロックフリーのルックアップが解放されたオブジェクトを逆参照しないようにします。
QEMU `virt` で `-smp 8` を使用した場合、カーネルは `login:` プロンプトまで確実に起動し、300回の反復の `pidin` ストレスループを停止なしで維持します。
---
## 7. ストレージ：`devb-nvme` と `fs-qrv`
マイクロカーネルモデルに忠実に、QRVのストレージは**2つの協調するユーザープロセス**であり、カーネルサブシステムではありません：
- **`devb-nvme`** — ブロックデバイスドライバー。PCIe経由でNVMeを話し（GPTパーティション解析を内蔵）、PCIサーバーを通じてコントローラーを発見し、`/dev/nvme0n1` やそのパーティションなどのブロックデバイスを提供します。（`devb-virtio` はエミュレートされたターゲット用にQEMU virtio-blkデバイスを駆動します。）
- **`fs-qrv`** — ファイルシステムリソースマネージャー。パーティションをマウントし、メッセージパッシングを介してPOSIXファイルシステム名前空間を提供します。アプリケーションの `open`/`read`/`write`/`close` は、`fs-qrv` が応答するメッセージになります。
典型的な起動では、実際のNVMeパーティションをマウントし、そこからプログラムを実行します：```
mount -t qrv /dev/nvme0n1p5 /disk2
このパス — ブロックドライバ、パーティショニング、ファイルシステムサーバ、およびカーネルがそれらの間のすべてのメッセージを仲介する — はQEMU上およびSiFive UnmatchedのNVMeドライブ上でエンドツーエンドで動作します。
QRVはsysinit/initを介して起動し、シリアルコンソールドライバ（QEMUではdevc-ser8250、FU740ではdevc-sersifive）、PCIサーバ、ストレージスタック、そしてgetty/loginを立ち上げ、シェルプロンプトに到達します。主要なユーザースペースプログラムは以下の通りです：
sh — mksh、MirBSD Kornシェル。 本格的なスクリプト可能なPOSIXシェルがシステムシェルです。ブートスクリプト（level1.sh、...）は通常のシェルスクリプトです。pidin — 古典的なQNXの「プロセス情報」ツール：プロセス、スレッド、その状態、メモリなどを一覧表示します。これはQRVの主要な「システムは正常に動作しているか？」を確認するプローブであり、標準的なストレステストワークロードです。lspci — PCIサーバを介してPCI/PCIeバスを列挙します。sloginfo — sloggerサーバによって収集されたシステムログをダンプします。これらに加えて、実用的なマルチユーザーシステムの構成要素があります：gettyとlogin（認証情報/認証サポート付き）、mount、shutdown、pipe、そしてコアユーティリティ（ls、cat、...）。すべてのQRVプログラムはマルチスレッドです — 最低でもメインスレッドとシステムスレッドがあります — これこそが正しいSMP同期（§6を参照）が非常に重要である理由です。
Cross-compiler : riscv64-linux-gnu-gcc CPU flags : -march=rv64g -mcmodel=medany -mno-relax Build style : -nostdinc -nostdlib -ffreestanding
### よく使うコマンド (`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)
主なテストプラットフォームは qemu-system-riscv64 上の virt マシンです。構成は Kconfig ベースです。
QRVの第二の、しかし真剣なターゲットは、SiFive Unmatched (FU740) — 実際のRISC-Vワークステーションボードです。QEMUで正常に起動するマイクロカーネルを物理シリコンでも正常に起動させることで、エミュレーションでは単に現れない種類のバグが表面化し、それらを追及することが最近のリリースの大部分を占めています。
代表的な例は v0.43 で修正されました: 2ヶ月間、QRVはQEMU上では完璧に動作し、実機では障害が発生しました。FU740では、どんなプログラム — pidin、lspci、何でも — が数回のスポーン後にクラッシュし、クラッシュは毎回異なり、プログラムカウンタはガベージをさまよっていました。原因はメモリ破損ではなく、命令キャッシュの非一貫性でした: RISC-Vはデータストアと命令フェッチの間の一貫性を保証しないため、ロードされたばかりのプログラムコードは、そのハートが fence.i を実行するまでハートのフェッチユニットから見えません。そして、ロードしたハートとは異なるハートで実行されるコードは、そのハートでリモートの fence.i を必要とします。QRVのローダーはそのどちらも行いませんでした（「I-cache無効化」フラグを計算した後、それを破棄することさえありました）。QEMUは命令キャッシュをモデル化していないため、バグはそこでは見えず、U74では決定論的でした。
修正 — ページが実行可能になるすべてのポイントでのローカルおよびSBIブロードキャストの fence.i (cpu_icache_sync_all()) — は、数回の実行ごとに障害が発生していたスポーンループを、FU740上で 600回連続してクリーンにスポーンする ものに変えました。最初に生まれた誤った仮説とそれを覆した診断を含む完全な調査は、『The QRV Porting Story』の第14章の結びのセクションです。
これまでに達成されたハードウェアのマイルストーンには、FU740上のユーザーモードのタスクマンで login: プロンプトまで起動すること、実際のNVMeパーティションからテストプログラムをマウントして実行することが含まれます。
QNXはこれまでに出荷された中で最も影響力のあるマイクロカーネル設計の一つです。そのsend/receive/replyモデルは、何世代ものシステムエンジニアに、クリーンなOSアーキテクチャがどのようなものかを教えてきました。しかし、それを具現化したコードは、10年以上もの間、奇妙な中途半端な状態にあります: コミュニティライセンスの下で研究するには十分に可視ですが、再配布、進化、または周りに活気あるエコシステムを構築するには十分にフリーではありません。このような優れた設計は、読み取り専用の遺物として保存されるだけの価値以上のものです。
それがこの作業が存在する理由です。QRVは、率直に言って、過渡的な乗り物です — 移植し、分解して新しいハードウェアで再構成し、カーネルロックを解除してプロセスマネージャをユーザースペースに持ち上げ、どの前提が負荷を支えているかを正確に発見することで、アーキテクチャを深く学ぶ方法です。実際のシリコン上で追跡されたすべてのバグ、64ビットクリーンに書き直されたすべてのサブシステム、解体されたすべてのプロプライエタリな境界は、真にフリーな実装が必要とする知識です。
なぜなら、長期的な目標は、誰か他のソースのパッチを当てたコピーを永遠に維持することではないからです。それは、QNXのインターフェースと互換性があり、そのマイクロカーネル哲学に忠実でありながら、プロプライエタリなコードに何も負わない、完全にフリーでスクラッチから作られたオペレーティングシステム — 誰の許可も求めずに使用、教育、出荷、改善できるものです。QRVは、そのようなシステムが可能であるだけでなく実用的であることを証明し、それを適切に構築するための経験を得る方法です。
歴史的な基盤そのものがフリーになることを望むなら、PETITION.md にあなたの名前を追加してください。そして、内部から見た現代の正直にエンジニアリングされたマイクロカーネルがどのようなものか見たいなら、レシピをクローンし、obtain_proj.sh を実行し、コードを読んでください。
QRV — QNX Neutrino 6.4 の64ビットハードウェアへの適応と再実装。2020年のクリスマスイブに開始。Apache 2.0（QRV自身のコード）+ BlackBerry QCL 2.0（QNX由来のソース）。コンポーネントごとの内訳は WHAT_IS_WHAT.md を参照してください。
| ファイル/ディレクトリ | 目的 |
|---|
obtain_proj.sh | 再構築スクリプト — これを実行します。 |
placement.txt | 各アップストリームQNXパスをQRVパスにマッピング（約680エントリ）。 |
patches/ | QRVパッチシリーズ（LZ4圧縮）、およびseries順序ファイル。 |
LICENSE.txt | Apache License 2.0。 |
WHAT_IS_WHAT.md | コンポーネントごとのライセンスと出所。 |
PETITION.md | 再ライセンス請願。 |