r-tty/qrvQRV Operating System
QRV — это комплексная адаптация и переосмысление операционной системы QNX Neutrino 6.4 для современного 64-разрядного оборудования, с RISC-V (rv64g) в качестве основной архитектуры и x86-64 в качестве вторичной целевой платформы. Проект начался в канун Рождества 2020 года. Название QRV намеренно избегает каких-либо ассоциаций с товарным знаком QNX.
QRV — это целая операционная система, а не просто ядро. Микроядро является её сердцем, но большая часть работы была вложена во всё, что его окружает. Наиболее заметен taskman — менеджер процессов/памяти/путей в пользовательском режиме (аналог QNX procnto), который был глубоко переработан и вынесен из ядра в пользовательское пространство; вместе с ним были портированы, приведены к 64-разрядному виду и во многих местах существенно переписаны библиотека C, драйверы устройств, файловая система, динамический загрузчик и системные серверы. Микроядро по замыслу невелико; операционная система вокруг него — вот где сосредоточена основная часть QRV.
Это не форк, который просто компилирует старый код новым компилятором. Это тщательный, модуль за модулем, порт на истинную модель LP64, с демонтированной границей проприетарного procnto, заменённой подсистемой IFS/startup и — начиная с последних версий — с полным удалением Большой блокировки ядра (Big Kernel Lock) и выносом менеджера процессов/памяти/путей из ядра в пользовательский сервер.
Этот README описывает QRV v0.43.
Блог разработки с полной историей порта находится по адресу https://r-tty.blogspot.com. Книжное повествование под названием The QRV Porting Story хранится в дереве исходников по пути doc/tex/PortingStory/.
QRV разрабатывался в тесном сотрудничестве с Claude Code — агентивным инструментом программирования от Anthropic; большая часть портирования, отладки SMP и документации (включая этот README) выполнялась как совместная работа человека и ИИ, бок о бок с автором.
obtain_proj.sh и дерево os/TM_PRIVdevb-nvme и fs-qrvQNX — это микроядерная операционная система реального времени, основная идея которой — синхронная передача сообщений. В QNX ядро само по себе крошечное: оно умеет планировать потоки, передавать сообщения, доставлять сигналы, обрабатывать таймеры и прерывания — и очень мало что ещё. Всё, что монолитная ОС поместила бы внутрь ядра — менеджер процессов, менеджер памяти, файловая система, драйверы устройств, сетевой стек, — работает в обычных пользовательских процессах, называемых менеджерами ресурсов, и они общаются друг с другом и со своими клиентами через тот же примитив IPC передать / принять / ответить.
Именно эта архитектура делает QNX элегантной, и именно её сохраняет QRV. Программа, желающая открыть файл, отправляет сообщение; сервер файловой системы принимает его, выполняет работу и отвечает. Ядро лишь выступает посредником при rendezvous. В результате получается система, в которой драйвер может упасть и быть перезапущен без остановки ядра, где доверенная вычислительная база измеряется десятками килобайт, а граница между «ядром» и «приложением» — это сообщение, а не стена привилегий, полная системных вызовов.
QRV берёт общедоступные исходники QNX Neutrino 6.4 из эпохи 2009 года и переносит этот дизайн вперёд:
int/uint32_t/pid_t на указателя, которыми изобилует 32-разрядный код.qemu-system-riscv64 (машина virt) и плата разработки SiFive Unmatched (FU740). x86-64 всё ещё собирается как проверка переносимости.mkifs (вместо этого QRV использует стандартный формат CPIO); нет отдельного разделения startup/ядро (startup слинкован напрямую с ядром); нет callout-ов и мини-драйверов.Kconfig, инкрементальная линковка ядра (модули добавляются и тестируются по одному, а не скармливаются линковщику как монолит 32→64), и кросс-компиляторная цепочка (riscv64-linux-gnu-gcc).procnto всюду называется taskman (Task Manager); все упоминания "Neutrino" удалены.QRV не реализует fork() (программы запускаются через posix_spawn()) и не имеет подкачки по требованию и swap'а — те же решения, которые QNX приняла в своём поколении 8.0.
QRV управляется одновременно двумя лицензиями, и понимание, какая из них где применяется, необходимо перед тем, как собирать или распространять что-либо.
Собственный код QRV лицензирован по Apache License 2.0. Всё, написанное с нуля для этого проекта — порт под RISC-V, новая система сборки, вынос taskman в пользовательский режим, переработка ядра без блокировок, написанные нами драйверы и инструменты, — распространяется под Apache 2.0. Полный текст находится в LICENSE.txt.
Код, производный от QNX, распространяется по лицензии BlackBerry QNX Community License (QCL) 2.0. Части QRV, происходящие из общедоступных исходников QNX Neutrino 2009 года, остаются под QCL, которая разрешает некоммерческое и академическое использование производных исходников. QRV не имеет права и не может перелицензировать код QNX.
Эта реальность с двумя лицензиями как раз и является причиной, по которой этот репозиторий не содержит готового к сборке дерева исходников. Нам не разрешено распространять исходники, производные от QNX. Поэтому вместо поставки кода этот репозиторий поставляет рецепт (см. следующий раздел): карту того, куда помещается каждый файл QNX, плюс патчи QRV, которые его преобразуют. Вы самостоятельно получаете вышестоящие общедоступные исходники QNX с их публичного зеркала, и рецепт восстанавливает дерево QRV на вашей машине. Ваша копия принадлежит вам; мы распространяем только наши собственные патчи и метаданные под лицензией Apache.
QRV также включает код под другими разрешительными лицензиями — например, компоненты под лицензией BSD, заимствованные из FreeBSD (заменяющие устаревшие модули QNX), блочный драйвер virtio под лицензией MIT родом из xv6, и оболочку системы MirBSD Korn shell (mksh). WHAT_IS_WHAT.md — это авторитетная, покомпонентная разбивка того, что под какой лицензией и откуда взялось; обращайтесь к ней всякий раз, когда не уверены в конкретном файле или подсистеме.
Наконец, в репозитории содержится PETITION.md: открытое обращение к QNX Software Systems и BlackBerry с просьбой перелицензировать исторические исходники Neutrino 2007–2009 годов под разрешительной лицензией, одобренной OSI. Если вы хотели бы, чтобы основы этой работы когда-нибудь стали полностью свободными, в этом документе можно добавить своё имя.
obtain_proj.sh и дерево os/Поскольку производные от QNX исходники не могут быть распространены здесь, этот репозиторий представляет собой дистрибутив для реконструкции исходников. Он содержит:
$ ./obtain_proj.sh
1. **Клонирует зеркало сообщества QNX upstream** (`github.com/vocho/openqnx`,
поверхностное клонирование).
2. **Размещает файлы** в соответствии с `placement.txt`, копируя каждый файл
из upstream в соответствующее место QRV в каталоге `os/`. Сообщает, сколько
файлов было размещено, уже присутствовало или отсутствовало.
3. **Удаляет клон** после завершения размещения.
4. **Применяет серию патчей QRV** из `patches/series`, по порядку. Каждый
патч сжат 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)** — единственный компонент, работающий в привилегированном режиме в классическом понимании. Его подсистемы малы и специализированы:
- **Передача сообщений** — `ker_message.c`, `ker_fastmsg.c`, `nano_message.c`
- **Каналы и соединения** — `ker_channel.c`, `ker_connect.c`
- **Потоки и планирование** — `ker_thread.c`, `ker_sched.c`, `nano_sched.c`
- **Синхронизация** — `ker_sync.c`, `nano_sync.c`
- **Сигналы** — `ker_signal.c`
- **Таймеры и часы** — `ker_timer.c`, `ker_clock.c`
- **Прерывания** — `ker_interrupt.c`
- **Диспетчеризация системных вызовов** — `ker_call_table.c`
- **Передача данных** — семейство `nano_xfer*.c` (межадресный движок копирования, безопасно перемещающий полезные данные сообщений между процессами)
Интерфейс между загрузчиком и ядром — это **syspage** (`include/sys/syspage.h`); состояние для каждого ЦП хранится в **cpupage**; полный контекст регистров — `RISCV_CPU_REGISTERS`. На RISC-V каждый «ЦП» идентифицируется своим **hart ID** везде — существует единое пространство имён для именования ЦП, от начала до конца.
**Всё остальное — это пользовательские процессы.** Менеджер процессов/памяти/путей, драйверы блочных и последовательных устройств, файловая система, PCI-сервер, системный журнал — все они являются менеджерами ресурсов, доступными через отправку сообщений. Ядро не содержит файловой системы; оно содержит возможность для одного процесса попросить другой *быть* файловой системой.
---
## 5. Taskman и привилегированный системный вызов `TM_PRIV`
**`taskman`** — это имя QRV для того, что в QNX называлось `procnto`: объединённый **менеджер процессов, менеджер памяти и менеджер путей (пространства имён)**. В классической системе QNX этот код был встроен в образ ядра. Одно из крупных структурных достижений QRV состоит в том, что **taskman теперь работает в пользовательском режиме** — это обычный процесс в U-режиме, не являющийся частью привилегированного ядра.
Это поднимает очевидный вопрос: если taskman находится в пользовательском пространстве, как он выполняет глубоко привилегированные действия, которые должен совершать менеджер процессов и памяти — манипулировать таблицами страниц, выделять физическую память, создавать и уничтожать адресные пространства, доставлять сигналы и импульсы, завершать процессы?
Ответ — это единственный, строго контролируемый шлюз: **`__KER_TM_PRIV`**, слот системного вызова 2. Это *единственная* дверь, через которую taskman получает доступ к привилегированным операциям ядра, и за этим одним слотом находится диспетчерская таблица из **~98 подопераций** — небольших **расширений ядра** («kerext»), каждое из которых выполняет одно чётко определённое привилегированное действие и возвращается. Несколько показательных семейств:
- **Жизненный цикл процессов** — `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` (операция когерентности кэша инструкций RISC-V, новая в v0.43)
Эта конструкция сохраняет **доверенную вычислительную базу небольшой** — само ядро остаётся минимальным — предоставляя taskman ровно те привилегированные примитивы, которые ему нужны, и **ничего больше**. Важно, что куча ядра и другие внутренние структуры ядра остаются недоступными для U-режима (страницы ядра имеют `PTE_U=0`); taskman выполняет свою работу через kerexts с копированием из/в пространство пользователя, никогда не получая сырой указатель на ядро. Перечисление находится в `kernel/include/ker+tm/tm_kercalls.h`; диспетчерская таблица — в `kernel/ker_tm_priv.c`.
---
## 6. Большая блокировка ядра — и её удаление
Ранний QRV — как и поколение QNX, от которого он произошёл, на многопроцессорных системах — защищал ядро с помощью одной **Большой блокировки ядра (BKL)**: глобального слова `inkernel`, которое допускало в ядро только один hart за раз. Независимо от того, сколько ЦП работало, каждый системный вызов и каждое сообщение taskman сериализовались через эту одну блокировку. Корректно, просто — и жёсткий предел для масштабируемости SMP.
**Начиная с v0.42, BKL удалена.** Это было заголовком длинной серии кандидатов на выпуск и темой глав 9–14 *The QRV Porting Story*. Системные вызовы и сообщения taskman теперь выполняются **одновременно на разных harts** под мелкозернистыми блокировками на каждый объект:
- **Блокировка на каждый объект.** Блокировка для каждого `tChannel` и для каждого `tConnect` защищают очереди сообщений; блокировка `vec_slock` для каждого процесса защищает вектор потоков; блокировка `sched_slock` диспетчера защищает очереди выполнения; блокировка `alloc_slock` защищает кучу ядра.
- **Безблокировочная передача сообщений.** `MsgSend` / `MsgReceive` / `MsgReply` и семейство `Sync*` **не используют глобальную блокировку вообще**. Взаимодействие между harts координируется с помощью мостиковых битов на поток и аппаратных барьеров памяти, а не взаимного исключения.
- **Восстановление SMR (эквивалент RCU).** Потоки, соединения и каналы удаляются через безопасное восстановление памяти, чтобы безблокировочные поиски никогда не разыменовывали освобождённый объект.
На QEMU `virt` с `-smp 8` ядро надёжно загружается до приглашения `login:` и выдерживает 300-итерационный стресс-цикл `pidin` без зависаний.
---
## 7. Хранилище: `devb-nvme` и `fs-qrv`
Верный модели микроядра, хранение в QRV реализовано как **два взаимодействующих пользовательских процесса**, не подсистема ядра:
- **`devb-nvme`** — драйвер блочных устройств. Он общается с NVMe через PCIe (со встроенным разбором GPT-разделов), обнаруживает контроллер через PCI-сервер и предоставляет блочные устройства, такие как `/dev/nvme0n1` и его разделы. (Существует родственный `devb-virtio` для управления устройством virtio-blk в QEMU для эмулированной цели.)
- **`fs-qrv`** — менеджер ресурсов файловой системы. Он монтирует раздел и обслуживает пространство имён POSIX-файловой системы через передачу сообщений: вызовы `open`/`read`/`write`/`close` приложения становятся сообщениями, на которые отвечает `fs-qrv`.
Типичная загрузка монтирует реальный NVMe-раздел и запускает программы с него:```
mount -t qrv /dev/nvme0n1p5 /disk2
Этот путь — драйвер блока, разметка, сервер файловой системы и ядро, управляющее каждым сообщением между ними — работает от начала до конца как на QEMU, так и на NVMe-накопителе SiFive Unmatched.
QRV загружается через sysinit/init, запускает драйвер последовательной консоли (devc-ser8250 на QEMU, devc-sersifive на FU740), PCI-сервер, стек хранения, и getty/login, и выводит вас в приглашение оболочки. Основные программы пользовательского пространства:
sh — mksh, оболочка Korn от MirBSD. Настоящая, скриптовая POSIX-оболочка является системной оболочкой; загрузочные скрипты (level1.sh, …) являются обычными shell-скриптами.pidin — классический инструмент QNX «информация о процессах»: выводит список процессов, потоков, их состояний, памяти и т.д. Это основной зонд QRV «жива ли система и работает ли нормально?» и стандартная нагрузка для стресс-тестирования.lspci — перечисляет шину PCI/PCIe через PCI-сервер.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: в течение двух месяцев QRV безупречно работал на QEMU и вылетал на железе. На FU740 любая программа — pidin, lspci, что угодно — падала после нескольких запусков, каждое падение отличалось от предыдущего, счётчик команд уходил в мусор. Причиной оказалось вовсе не повреждение памяти, а несогласованность кэша инструкций: RISC-V не гарантирует согласованности между записями данных и выборкой инструкций, поэтому только что загруженный код программы невидим для модуля выборки hart, пока этот hart не выполнит fence.i — а код, который будет выполняться на другом hart, чем тот, который его загрузил, требует удалённого fence.i там. Загрузчик QRV не делал ни того, ни другого (он даже вычислял флаг «аннулировать I-кэш», а затем выбрасывал его). QEMU не моделирует кэш инструкций, поэтому ошибка была невидима там и детерминирована на U74.
Исправление — локальный плюс широковещательный через SBI fence.i (cpu_icache_sync_all()) в каждой точке, где страница становится исполняемой — превратило цикл порождения, который падал через каждые несколько запусков, в цикл, который отработал более 600 последовательных запусков чисто на FU740. Полное расследование, включая ложную гипотезу, которую оно сначала породило, и диагностику, которая её опровергла, является заключительным разделом главы 14 Истории портирования QRV.
Достигнутые на данный момент аппаратные вехи включают загрузку до приглашения login: в пользовательском режиме taskman на FU740, а также монтирование и запуск тестовых программ с реального раздела NVMe.
QNX — одна из самых влиятельных конструкций микроядер, когда-либо выпущенных. Её модель send/receive/reply научила поколения системных инженеров тому, как может выглядеть чистая архитектура ОС. И всё же код, который её воплощает, провёл более десяти лет в своеобразном лимбе: достаточно видимый для изучения по общественной лицензии, но недостаточно свободный для распространения, развития или построения вокруг него живого сообщества. Такая хорошая конструкция заслуживает большего, чем быть сохранённой только как артефакт только для чтения.
Именно поэтому и существует эта работа. 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 | Петиция о перелицензировании. |