r-tty/qrvSystème d'exploitation QRV
QRV est une adaptation et une réimplémentation complète du système d'exploitation QNX Neutrino
6.4 pour du matériel 64 bits moderne, avec RISC-V (rv64g)
comme architecture principale et x86-64 comme cible secondaire. Le
projet a débuté la veille de Noël 2020. Le nom QRV évite délibérément
toute association avec la marque QNX.
QRV est un système d'exploitation complet, pas seulement un noyau. Le micro-noyau en est
le cœur — mais la plus grande partie du travail a porté sur tout ce qui
l'entoure. Le plus notable est taskman, le gestionnaire de processus / mémoire / chemins en mode utilisateur (le procnto de QNX), qui a été profondément retravaillé et sorti
du noyau dans l'espace utilisateur ; à côté de cela, la bibliothèque C, les pilotes
de périphériques, le système de fichiers, le chargeur dynamique et les serveurs système ont
tous été portés, rendus compatibles 64 bits et, à de nombreux endroits, considérablement
réécrits. Le micro-noyau est petit par conception ; le système d'exploitation qui l'entoure
est là où vit la majeure partie de QRV.
Ce n'est pas un fork qui se contente de compiler du code ancien sur un nouveau compilateur. C'est un
portage minutieux, module par module, vers un vrai modèle LP64, avec la
frontière propriétaire procnto démantelée, les mécanismes IFS/startup
remplacés, et — depuis les versions les plus récentes — le verrou global du noyau
supprimé entièrement et le gestionnaire de processus/mémoire/chemins sorti du
noyau dans un serveur en mode utilisateur.
Ce README décrit QRV v0.43.
Le blog de développement, avec l'histoire complète du portage, se trouve à
https://r-tty.blogspot.com. Un récit de la longueur d'un livre, The QRV Porting
Story, se trouve dans l'arborescence source sous doc/tex/PortingStory/.
QRV a été développé en étroite collaboration avec Claude Code, l'outil de codage agentique d'Anthropic — une grande partie du portage, du débogage SMP et de la documentation (y compris ce README) a été réalisée dans le cadre d'un effort de programmation en binôme humain-IA, aux côtés de l'auteur.
obtain_proj.sh et l'arborescence os/TM_PRIVdevb-nvme et fs-qrvQNX est un système d'exploitation temps réel à micro-noyau dont l'idée fondatrice est le passage de messages synchrone. Dans QNX, le noyau lui-même est minuscule — il sait comment ordonnancer les threads, passer des messages, délivrer des signaux, gérer les temporisateurs et les interruptions, et très peu d'autres choses. Tout ce qu'un système d'exploitation monolithique mettrait à l'intérieur du noyau — le gestionnaire de processus, le gestionnaire de mémoire, le système de fichiers, les pilotes de périphériques, la pile réseau — s'exécute dans des processus utilisateur ordinaires appelés gestionnaires de ressources, et ils communiquent entre eux et avec leurs clients via la même primitive IPC envoyer / recevoir / répondre.
Cette architecture est ce qui rend QNX élégant, et c'est exactement ce que QRV préserve. Un programme qui veut ouvrir un fichier envoie un message ; le serveur de système de fichiers le reçoit, fait le travail et répond. Le noyau ne fait que négocier le rendez-vous. Le résultat est un système où un pilote peut planter et être redémarré sans faire tomber le noyau, où la base de confiance de calcul est mesurée en dizaines de kilo-octets, et où la frontière entre « noyau » et « application » est un message, pas un mur de privilèges rempli d'appels système.
QRV prend les sources communautaires de QNX Neutrino 6.4 de l'ère 2009 et fait évoluer cette conception :
int/uint32_t/pid_t-sur-pointeur
dont le code 32 bits est truffé.qemu-system-riscv64 (la machine
virt) et la carte de développement SiFive Unmatched (FU740). x86-64 est
maintenue en compilation comme vérification de portabilité.mkifs (QRV utilise
le format standard CPIO à la place) ; il n'y a pas de séparation startup/noyau
(startup est lié directement avec le noyau) ; il n'y a pas
de callouts et pas de mini-pilotes.Kconfig de style Linux, une
édition de liens incrémentale du noyau (les modules sont ajoutés et testés un par un, pas jetés au
lieur comme un monolithe 32→64), et une chaîne d'outils de compilation croisée
(riscv64-linux-gnu-gcc).procnto est taskman (le
gestionnaire de tâches) partout ; toutes les références à « Neutrino » sont supprimées.QRV n'implémente pas fork() (les programmes démarrent via posix_spawn()),
et il n'y a pas de pagination à la demande et pas de swap — les mêmes choix que QNX
a faits dans sa génération 8.0.
QRV est régi par deux licences à la fois, et comprendre laquelle est laquelle est essentiel avant de construire ou de redistribuer quoi que ce soit.
Le code propre de QRV est sous licence Apache 2.0. Tout ce qui est écrit à partir de zéro
pour ce projet — le portage RISC-V, le nouveau système de construction, la séparation de taskman en espace utilisateur,
la refonte du noyau sans verrou, les pilotes et les outils que nous avons
créés — est sous Apache 2.0. Le texte complet se trouve dans LICENSE.txt.
Le code dérivé de QNX est sous BlackBerry QNX Community License (QCL) 2.0. Les parties de QRV qui descendent des sources communautaires de QNX Neutrino de 2009 restent sous la QCL, qui permet l'utilisation non commerciale et académique des sources dérivées. QRV ne peut pas, et ne peut pas, re-licencier le code de QNX.
Cette réalité de double licence est précisément la raison pour laquelle ce dépôt ne contient pas d'arborescence source prête à construire. Nous n'avons pas la permission de redistribuer les sources dérivées de QNX. Ainsi, au lieu de distribuer le code, ce dépôt fournit une recette (voir la section suivante) : une carte de l'endroit où chaque fichier QNX va, plus les correctifs QRV qui le transforment. Vous obtenez les sources communautaires QNX amont vous-même, depuis leur miroir public, et la recette reconstruit l'arbre QRV sur votre machine. Votre copie est la vôtre ; nous redistribuons uniquement nos propres correctifs et métadonnées sous licence Apache.
QRV intègre également du code sous d'autres licences permissives — par exemple
des composants sous licence BSD adoptés depuis FreeBSD (remplaçant des modules QNX vieillissants),
un pilote de bloc virtio sous licence MIT d'ascendance xv6, et le shell Korn
MirBSD (mksh) comme shell système. WHAT_IS_WHAT.md est la référence
composant par composant de ce qui est sous quelle licence et d'où cela
vient — consultez-le chaque fois que vous avez un doute sur un fichier ou un sous-système
particulier.
Enfin, le dépôt contient PETITION.md : une demande ouverte à QNX
Software Systems et BlackBerry pour relicencier les sources historiques de Neutrino
2007–2009 sous une licence permissive approuvée par l'OSI. Si vous souhaitez
que les fondations de ce travail soient un jour entièrement libres, ce document est
l'endroit où ajouter votre nom.
obtain_proj.sh et l'arborescence os/Parce que les sources dérivées de QNX ne peuvent pas être redistribuées ici, ce dépôt est une distribution de reconstruction de sources. Il contient :
$ ./obtain_proj.sh
1. **Clone le miroir communautaire amont de QNX** (`github.com/vocho/openqnx`, un clone superficiel).
2. **Place les fichiers** selon `placement.txt`, en copiant chaque fichier amont dans son emplacement QRV sous `os/`. Il indique combien de fichiers ont été placés, déjà présents ou manquants.
3. **Supprime le clone** une fois le placement terminé.
4. **Applique la série de correctifs QRV** depuis `patches/series`, dans l'ordre. Chaque correctif est compressé en LZ4 (`*.patch.lz4`) et appliqué avec `lz4cat … | patch -p1`. Les correctifs portent la version de la version actuelle.
5. **Définit les permissions exécutables** sur les quelques scripts qui en ont besoin (par ex. `emu.sh`, `host_tools/mkgpt.py`).
Les outils requis sont `git`, `patch` et `lz4cat` (du paquet `lz4`); le script vérifie leur présence au préalable et vous indique comment installer ceux qui manquent.
Le résultat final est **`os/`** — un arbre source QRV complet et constructible :```
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
À partir de là, cd os && make construit le système (voir §9).
QRV est un véritable système micro-noyau. La pile de privilèges, du métal vers le haut, se présente comme ceci sur 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 │ └───────────────────────────────────────────────────────────────────────┘
**Le noyau (mode S)** est le seul composant qui s’exécute en mode privilégié
au sens classique. Ses sous-systèmes sont petits et ciblés :
- **Passage de messages** — `ker_message.c`, `ker_fastmsg.c`, `nano_message.c`
- **Canaux et connexions** — `ker_channel.c`, `ker_connect.c`
- **Threads et ordonnancement** — `ker_thread.c`, `ker_sched.c`, `nano_sched.c`
- **Synchronisation** — `ker_sync.c`, `nano_sync.c`
- **Signaux** — `ker_signal.c`
- **Minuteries et horloges** — `ker_timer.c`, `ker_clock.c`
- **Interruptions** — `ker_interrupt.c`
- **Dispatch des appels système** — `ker_call_table.c`
- **Transfert de données** — la famille `nano_xfer*.c` (le moteur de copie
inter-espaces d’adressage qui déplace les charges utiles des messages en
toute sécurité entre les processus)
L’interface entre l’amorceur et le noyau est la **syspage**
(`include/sys/syspage.h`) ; l’état par CPU réside dans la **cpupage** ; le
contexte complet des registres est `RISCV_CPU_REGISTERS`. Sur RISC-V, chaque
« CPU » est identifié partout par son **hart ID** — il y a un espace de
noms unique pour les CPU, de bout en bout.
**Tout le reste est un processus utilisateur.** Le gestionnaire de
processus/mémoire/chemins, les pilotes bloc et série, le système de
fichiers, le serveur PCI, le journal système — tous sont des gestionnaires
de ressources atteints en envoyant un message. Le noyau ne contient pas de
système de fichiers ; il contient la capacité pour un processus de
demander à un autre d’*être* un système de fichiers.
---
## 5. Taskman et l’appel système privilégié `TM_PRIV`
**`taskman`** est le nom que QRV donne à ce que QNX appelait `procnto` : le
**gestionnaire de processus, de mémoire et de chemins (espace de noms)**
combiné. Dans un système QNX classique, ce code est fusionné dans l’image
du noyau. L’une des grandes réalisations structurelles de QRV est que
**taskman s’exécute désormais en mode utilisateur** — c’est un processus
ordinaire en mode U, pas une partie du noyau privilégié.
Cela soulève une question évidente : si taskman vit dans l’espace
utilisateur, comment fait-il pour effectuer les opérations profondément
privilégiées qu’un gestionnaire de processus et de mémoire doit accomplir —
manipuler les tables de pages, allouer la RAM physique, créer et détruire
les espaces d’adressage, délivrer signaux et impulsions, détruire les
processus ?
La réponse est une passerelle unique, étroitement contrôlée :
**`__KER_TM_PRIV`**, emplacement d’appel système 2. C’est la *seule* porte
par laquelle taskman accède aux opérations privilégiées du noyau, et
derrière cet emplacement unique se trouve une table de dispatch d’environ
**98 sous-opérations** — de petites **extensions du noyau** (« kerexts »)
qui effectuent chacune une action privilégiée bien définie et retournent.
Quelques familles représentatives :
- **Cycle de vie des processus** — `PROCESS_CREATE`, `PROCESS_EXEC`,
`PROCESS_DESTROY`, `PROCESS_STARTUP`, `PROCESS_SHUTDOWN`, `REPARENT`
- **Mémoire physique et virtuelle** — `PA_ALLOC`, `PA_FREE`,
`PA_QUANTUM_TO_PADDR`, `PAGE_CONT`, `STACK_CONT`, `ASPACE_MEMCPY`
- **Identifiants et limites** — `CRED_GET`, `CRED_SET`, `LIMITS_GET/SET`
- **Distribution et objets** — `PULSE_DELIVER`, `SIGNAL_DELIVER`,
`QUERY_OBJECT`, `CHANNEL_DESTROY`, `CONNECT_DETACH`
- **SMP et plateforme** — `SMP_BRINGUP`, `LEGAL_CPU_MASK`, `GET_KERN_PGDIR`,
`ICACHE_SYNC` (l’opération de cohérence du cache d’instructions RISC-V,
nouvelle dans la v0.43)
Cette conception maintient une **base de confiance réduite** — le noyau
proprement dit reste minimal — tout en donnant à taskman exactement les
primitives privilégiées dont il a besoin et **rien de plus**. De manière
cruciale, le tas du noyau et les autres éléments internes du noyau
restent inaccessibles depuis le mode U (les pages du noyau conservent
`PTE_U=0`) ; taskman accomplit son travail via des kerexts de copie
entrée/sortie, jamais en recevant un pointeur brut du noyau. L’énumération
se trouve dans `kernel/include/ker+tm/tm_kercalls.h` ; la table de dispatch
est dans `kernel/ker_tm_priv.c`.
---
## 6. Le verrou global du noyau — et sa suppression
Le QRV primitif — comme la génération QNX dont il est issu sur les systèmes
multiprocesseurs — protégeait le noyau avec un seul **verrou global du
noyau (BKL)** : un mot global `inkernel` qui n’admettait qu’un seul hart
dans le noyau à la fois. Quel que soit le nombre de CPU en cours
d’exécution, chaque appel système et chaque message de taskman passait en
série par ce verrou. Correct, simple — et un plafond rigide pour la
passage à l’échelle SMP.
**Depuis la v0.42, le BKL a disparu.** C’était le titre d’une longue série
de versions candidates et le sujet des chapitres 9 à 14 de *The QRV Porting
Story*. Les appels système et les messages de taskman s’exécutent maintenant
**simultanément sur tous les harts** sous des verrous fins, par objet :
- **Verrouillage par objet.** Un verrou par `tChannel` et par `tConnect`
protège les files de messages ; un `vec_slock` par processus protège le
vecteur de threads ; un `sched_slock` par dispatch protège les files
d’attente d’exécution ; un `alloc_slock` protège le tas du noyau.
- **Passage de messages sans verrou.** `MsgSend` / `MsgReceive` / `MsgReply`
et la famille `Sync*` ne prennent **aucun verrou global**. Le rendez-vous
inter-hart est coordonné par des bits de pont par thread et des barrières
mémoire matérielles plutôt que par exclusion mutuelle.
- **Réclamation SMR (équivalent RCU).** Les threads, connexions et canaux
sont retirés via une réclamation mémoire sûre afin que les recherchess
sans verrou ne déréférencent jamais un objet libéré.
Sur QEMU `virt` avec `-smp 8`, le noyau démarre de manière fiable jusqu’à
une invite `login:` et soutient une boucle de stress `pidin` de 300
itérations sans blocage.
---
## 7. Stockage : `devb-nvme` et `fs-qrv`
Conformément au modèle du micro-noyau, le stockage dans QRV est **deux
processus utilisateur coopérants**, pas un sous-système du noyau :
- **`devb-nvme`** — le pilote de périphérique bloc. Il parle NVMe sur PCIe
(avec analyse des partitions GPT intégrée), découvre le contrôleur via le
serveur PCI, et présente des périphériques bloc comme `/dev/nvme0n1` et
ses partitions. (Un frère `devb-virtio` pilote le périphérique QEMU
virtio-blk pour la cible émulée.)
- **`fs-qrv`** — le gestionnaire de ressources du système de fichiers. Il
monte une partition et sert l’espace de noms POSIX du système de fichiers
via le passage de messages : les `open` / `read` / `write` / `close` d’une
application deviennent des messages auxquels `fs-qrv` répond.
Un démarrage typique monte une partition NVMe réelle et exécute des
programmes depuis celle-ci :```
mount -t qrv /dev/nvme0n1p5 /disk2
This path — pilote de bloc, partitionnement, serveur de système de fichiers, et le noyau faisant office de courtier pour chaque message entre eux — fonctionne de bout en bout à la fois sur QEMU et sur le lecteur NVMe du SiFive Unmatched.
QRV démarre via sysinit/init, met en route le pilote de console série (devc-ser8250 sur QEMU, devc-sersifive sur le FU740), le serveur PCI, la pile de stockage, et getty/login, et vous amène à une invite de shell. Les programmes phares de l'espace utilisateur :
sh — mksh, le shell Korn MirBSD. Un vrai shell POSIX scriptable est le shell système ; les scripts de démarrage (level1.sh, …) sont des scripts shell ordinaires.pidin — l'outil classique QNX d'information sur les processus : liste les processus, les threads, leurs états, la mémoire, etc. C'est la sonde principale de QRV pour savoir « le système est-il vivant et en bonne santé ? » et sa charge de travail standard de test de stress.lspci — énumère le bus PCI/PCIe via le serveur PCI.sloginfo — vide le journal système collecté par le serveur slogger.À côté de ceux-ci se trouvent les blocs de construction d'un système multi-utilisateur utilisable : getty et login (avec support des identifiants/authentification), mount, shutdown, pipe, et les utilitaires de base (ls, cat, …). Chaque programme QRV est multi-thread — au minimum un thread principal et un thread système — ce qui explique exactement pourquoi une synchronisation SMP correcte (voir §6) est si importante.
Cross-compiler : riscv64-linux-gnu-gcc CPU flags : -march=rv64g -mcmodel=medany -mno-relax Build style : -nostdinc -nostdlib -ffreestanding
### Commandes courantes (exécutées dans `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)
La plateforme de test principale est qemu-system-riscv64 sur la machine
virt. La configuration est basée sur Kconfig.
La cible secondaire mais sérieuse de QRV est la SiFive Unmatched (FU740) — une véritable carte de bureau RISC-V. Faire en sorte qu'un micro-noyau qui démarre proprement sur QEMU démarre également proprement sur du silicium physique a révélé une classe de bugs que l'émulation ne présente tout simplement pas, et leur traque constitue une grande partie de ce que les versions récentes apportent.
L'exemple déterminant, corrigé dans v0.43 : pendant deux mois, QRV fonctionnait parfaitement
sur QEMU et plantait sur le matériel. Sur la FU740, n'importe quel programme — pidin,
lspci, n'importe quoi — plantait après quelques lancements, chaque crash
différent du précédent, le compteur de programme se perdant dans du bruit.
La cause ne s'est pas avérée être une corruption mémoire, mais une incohérence du cache
d'instructions : RISC-V ne garantit aucune cohérence entre les magasins de données et
le chargement d'instructions, donc le code de programme fraîchement chargé est invisible pour
l'unité de chargement d'un hart jusqu'à ce que ce hart exécute fence.i — et le code qui
s'exécutera sur un hart différent de celui qui l'a chargé nécessite un fence.i distant
là-bas. Le chargeur de QRV ne faisait ni l'un ni l'autre (il calculait même un indicateur
"invalider le cache I" puis le jetait). QEMU ne modélise aucun cache d'instructions, donc le
bug était invisible là-bas et déterministe sur l'U74.
Le correctif — un fence.i local plus une diffusion SBI (cpu_icache_sync_all()) à
chaque point où une page devient exécutable — a transformé une boucle de lancement qui
plantait toutes les quelques exécutions en une boucle qui a fonctionné proprement pendant
plus de 600 lancements consécutifs sur la FU740. L'investigation complète, y compris
l'hypothèse erronée qu'elle a d'abord produite et le diagnostic qui l'a renversée, constitue
la section de clôture du chapitre 14 de The QRV Porting Story.
Les étapes matérielles franchies jusqu'à présent incluent le démarrage jusqu'à une invite
login: dans le gestionnaire de tâches en mode utilisateur sur la FU740, et le montage et
l'exécution de programmes de test à partir d'une véritable partition NVMe.
QNX est l'un des designs de micro-noyau les plus influents jamais livrés. Son modèle envoi/réception/réponse a enseigné à des générations d'ingénieurs système à quoi une architecture OS propre peut ressembler. Et pourtant, le code qui l'incarne a passé plus d'une décennie dans une étrange situation de flou : assez visible pour être étudié sous une licence communautaire, mais pas assez libre pour être redistribué, modifié, ou servir de base à un écosystème vivant. Un design aussi bon mérite mieux que d'être conservé uniquement comme un artefact en lecture seule.
C'est la raison pour laquelle ce travail existe. QRV est, franchement, un véhicule transitoire — un moyen d'apprendre l'architecture en profondeur en la portant, en la démontant et en la remontant sur du nouveau matériel, en supprimant le verrou du noyau et en faisant passer le gestionnaire de processus dans l'espace utilisateur et en découvrant exactement quelles hypothèses étaient porteuses. Chaque bug traqué sur du silicium réel, chaque sous-système réécrit pour être propre en 64 bits, chaque frontière propriétaire démantelée, est une connaissance dont une implémentation vraiment libre aura besoin.
Parce que l'objectif à long terme n'est pas de maintenir une copie modifiée des sources de quelqu'un d'autre pour toujours. C'est un système d'exploitation entièrement libre, écrit de zéro, compatible avec les interfaces de QNX et fidèle à sa philosophie de micro-noyau, mais ne devant rien au code propriétaire — un système qui peut être utilisé, enseigné, distribué et amélioré sans demander la permission à personne. QRV est la manière dont nous prouvons qu'un tel système est non seulement possible mais pratique, et comment nous acquérons l'expérience pour le construire correctement.
Si vous souhaitez que les fondations historiques elles-mêmes deviennent libres, ajoutez
votre nom à PETITION.md. Et si vous souhaitez voir à quoi ressemble un micro-noyau
moderne et honnêtement conçu de l'intérieur — clonez la recette, exécutez obtain_proj.sh,
et lisez le code.
QRV — adaptation et réimplémentation de QNX Neutrino 6.4 pour du matériel
64 bits. Commencé la veille de Noël 2020. Apache 2.0 (code propre de QRV) +
BlackBerry QCL 2.0 (sources dérivées de QNX). Voir WHAT_IS_WHAT.md pour la
répartition composant par composant.
| Fichier / dossier | Objectif |
|---|
obtain_proj.sh | Le script de reconstruction — exécutez-le. |
placement.txt | Mappe chaque chemin QNX amont vers son chemin QRV (≈680 entrées). |
patches/ | La série de correctifs QRV, compressée en LZ4, plus un fichier d'ordre series. |
LICENSE.txt | Licence Apache 2.0. |
WHAT_IS_WHAT.md | Licence et provenance composant par composant. |
PETITION.md | La pétition de relicenciement. |