QRV — एक QNX Neutrino-आधारित ऑपरेटिंग सिस्टम, 64-बिट RISC-V के लिए पुनर्कल्पित

QRV, आधुनिक 64-बिट हार्डवेयर के लिए QNX Neutrino 6.4 ऑपरेटिंग सिस्टम का एक नए सिरे से अनुकूलन और पुनः कार्यान्वयन है, जिसमें RISC-V (rv64g) प्राथमिक आर्किटेक्चर और x86-64 द्वितीयक लक्ष्य है। परियोजना 24 दिसंबर 2020 को शुरू हुई। QRV नाम जानबूझकर QNX ट्रेडमार्क से किसी भी जुड़ाव से बचता है।

QRV एक संपूर्ण ऑपरेटिंग सिस्टम है, केवल एक कर्नेल नहीं। माइक्रोकर्नेल इसका दिल है — लेकिन अधिकांश काम उस चीज़ पर गया है जो इसके चारों ओर है। सबसे उल्लेखनीय है टास्कमैन (taskman), यूज़र-मोड प्रक्रिया/मेमोरी/पथ प्रबंधक (QNX का procnto), जिसे गहराई से फिर से काम किया गया है और कर्नेल से बाहर यूज़र स्पेस में उठा लिया गया है; इसके साथ ही C लाइब्रेरी, डिवाइस ड्राइवर, फाइलसिस्टम, डायनामिक लोडर और सिस्टम सर्वर सभी को पोर्ट किया गया है, 64-बिट स्वच्छ बनाया गया है, और कई स्थानों पर काफी हद तक फिर से लिखा गया है। माइक्रोकर्नेल डिज़ाइन द्वारा छोटा है; इसके आस-पास का ऑपरेटिंग सिस्टम वह है जहाँ QRV का अधिकांश भाग रहता है।

यह कोई ऐसा फोर्क नहीं है जो केवल एक नए कंपाइलर पर पुराने कोड को संकलित करता है। यह एक सावधानीपूर्वक, मॉड्यूल-दर-मॉड्यूल पोर्ट है एक सच्चे LP64 मॉडल के लिए, जिसमें मालिकाना procnto सीमा को तोड़ दिया गया है, IFS/स्टार्टअप तंत्र को बदल दिया गया है, और — नवीनतम रिलीज़ के अनुसार — कर्नेल के बिग कर्नेल लॉक को पूरी तरह से हटा दिया गया है और प्रक्रिया/मेमोरी/पथ प्रबंधक को कर्नेल से बाहर एक यूज़र-मोड सर्वर में ले जाया गया है।

यह README QRV v0.43 का वर्णन करता है।

डेवलपमेंट ब्लॉग, पोर्ट की पूरी कहानी के साथ, https://r-tty.blogspot.com पर है। एक पुस्तक-लंबाई की कथा, The QRV Porting Story, स्रोत ट्री में doc/tex/PortingStory/ के अंतर्गत है।

QRV को Claude Code, Anthropic के एजेंटिक कोडिंग टूल के साथ घनिष्ठ सहयोग में विकसित किया गया है — पोर्टिंग, SMP डिबगिंग और डॉक्यूमेंटेशन (इस README सहित) का अधिकांश भाग लेखक के साथ मानव–AI जोड़ी-प्रोग्रामिंग प्रयास के रूप में किया गया था।

सामग्री

QRV क्या है
लाइसेंसिंग
स्रोत प्राप्त करना: obtain_proj.sh और os/ ट्री
सिस्टम आर्किटेक्चर
टास्कमैन और TM_PRIV विशेषाधिकार प्राप्त सिस्कॉल
बिग कर्नेल लॉक — और इसका हटाया जाना
स्टोरेज: devb-nvme और fs-qrv
यूज़र स्पेस
बिल्डिंग और चलाना
वास्तविक हार्डवेयर पर चलाना
समापन टिप्पणी: एक मुफ़्त क्लोन क्यों मायने रखता है

1. QRV क्या है

QNX एक माइक्रोकर्नेल रियल-टाइम ऑपरेटिंग सिस्टम है जिसका परिभाषित विचार सिंक्रोनस मैसेज पासिंग है। QNX में, कर्नेल स्वयं छोटा होता है — यह जानता है कि थ्रेड को शेड्यूल कैसे करना है, संदेश कैसे पास करने हैं, सिग्नल कैसे डिलीवर करने हैं, टाइमर और इंटरप्ट को कैसे संभालना है, और बहुत कम और कुछ। वह सब कुछ जो एक मोनोलिथिक OS कर्नेल के अंदर रखेगा — प्रक्रिया प्रबंधक, मेमोरी प्रबंधक, फाइलसिस्टम, डिवाइस ड्राइवर, नेटवर्क स्टैक — सामान्य यूज़र प्रक्रियाओं में चलते हैं जिन्हें रिसोर्स मैनेजर कहा जाता है, और वे एक-दूसरे से और अपने क्लाइंट से उसी send / receive / reply IPC प्रिमिटिव के माध्यम से बात करते हैं।

यह आर्किटेक्चर ही QNX को सुरुचिपूर्ण बनाता है, और QRV बिल्कुल यही संरक्षित करता है। एक प्रोग्राम जो फ़ाइल खोलना चाहता है, वह एक संदेश भेजता है; फाइलसिस्टम सर्वर इसे प्राप्त करता है, काम करता है, और उत्तर देता है। कर्नेल केवल रेंडेज़वस की मध्यस्थता करता है। परिणाम एक ऐसा सिस्टम है जहाँ एक ड्राइवर क्रैश हो सकता है और कर्नेल को नीचे लाए बिना पुनः आरंभ किया जा सकता है, जहाँ विश्वसनीय कंप्यूटिंग बेस दसियों किलोबाइट में मापा जाता है, और जहाँ "कर्नेल" और "एप्लिकेशन" के बीच की सीमा एक संदेश है, न कि सिस्कॉल से भरी विशेषाधिकार दीवार।

QRV 2009-युग के QNX Neutrino 6.4 सामुदायिक स्रोतों को लेता है और उस डिज़ाइन को आगे लाता है:

64-बिट स्वच्छ (LP64). हर पॉइंटर और आकार प्रकार 64-बिट है; पोर्ट int/uint32_t/pid_t-ऑन-पॉइंटर ट्रंकेशन को ढूंढता और ठीक करता है जो 32-बिट कोड से भरे होते हैं।
RISC-V पहले. प्राथमिक लक्ष्य qemu-system-riscv64 (virt मशीन) और SiFive Unmatched (FU740) डेवलपमेंट बोर्ड है। x86-64 को पोर्टेबिलिटी जांच के रूप में बनाए रखा जाता है।
कोई मालिकाना सीमाएँ नहीं। कोई IFS और कोई mkifs नहीं है (QRV इसके बजाय मानक CPIO प्रारूप का उपयोग करता है); कोई अलग स्टार्टअप/कर्नेल विभाजन नहीं है (स्टार्टअप सीधे कर्नेल से जुड़ा हुआ है); कोई कॉलआउट और कोई मिनी-ड्राइवर नहीं हैं।
एक आधुनिक बिल्ड. एक Linux-शैली Kconfig कॉन्फ़िगरेशन, एक वृद्धिशील कर्नेल लिंक (मॉड्यूल को एक साथ 32→64 मोनोलिथ के रूप में लिंकर पर नहीं फेंका जाता, बल्कि एक-एक करके जोड़ा और परीक्षण किया जाता है), और एक क्रॉस-कंपाइलर टूलचेन (riscv64-linux-gnu-gcc)।
एक नाम-परिवर्तित, डी-ट्रेडमार्कित शब्दावली। procnto पूरे स्थान पर टास्कमैन (taskman) (कार्य प्रबंधक) है; सभी "Neutrino" संदर्भ हटा दिए गए हैं।

QRV fork() को लागू नहीं करता है (प्रोग्राम posix_spawn() के माध्यम से शुरू होते हैं), और इसमें कोई डिमांड पेजिंग और कोई स्वैप नहीं है — वही विकल्प जो QNX ने अपनी 8.0 पीढ़ी में चुने थे।

2. लाइसेंसिंग

QRV एक साथ दो लाइसेंसों द्वारा शासित है, और यह समझना कि कौन सा कौन सा है, इससे पहले कि आप कुछ भी बनाएँ या पुनर्वितरित करें, आवश्यक है।

QRV का अपना कोड Apache License 2.0 है। इस परियोजना के लिए खरोंच से लिखी गई हर चीज़ — RISC-V पोर्ट, नई बिल्ड सिस्टम, यूज़र-मोड टास्कमैन विभाजन, लॉक-फ्री कर्नेल रीवर्क, हमारे द्वारा लिखे गए ड्राइवर और टूलिंग — Apache 2.0 है। पूरा पाठ LICENSE.txt में है।
QNX-व्युत्पन्न कोड BlackBerry QNX Community License (QCL) 2.0 है। QRV के वे भाग जो 2009 के QNX Neutrino सामुदायिक स्रोतों से उत्पन्न हुए हैं, वे 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 सॉफ़्टवेयर सिस्टम्स और BlackBerry से एक खुला अनुरोध कि वे ऐतिहासिक 2007–2009 Neutrino स्रोतों को एक अनुमेय OSI-अनुमोदित लाइसेंस के तहत पुनः लाइसेंस करें। यदि आप चाहते हैं कि इस कार्य की नींव एक दिन पूरी तरह से मुक्त हो, तो वह दस्तावेज़ वह स्थान है जहाँ आप अपना नाम जोड़ सकते हैं।

3. स्रोत प्राप्त करना: `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).

4. प्रणाली वास्तुकला

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 │ └───────────────────────────────────────────────────────────────────────┘

**कर्नेल (S-मोड)** एकमात्र घटक है जो क्लासिक अर्थों में विशेषाधिकार प्राप्त रूप में चलता है। इसके उपप्रणालियाँ छोटी और केंद्रित हैं:

- **संदेश प्रेषण** — `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`) है; प्रति-CPU स्थिति **cpupage** में रहती है; पूर्ण रजिस्टर संदर्भ `RISCV_CPU_REGISTERS` है। RISC-V पर, प्रत्येक "CPU" की पहचान हर जगह उसके **hart ID** द्वारा होती है — एक एकल CPU-नामकरण नामस्थान है, अंत से अंत तक।

**बाकी सब कुछ एक उपयोगकर्ता प्रक्रिया है।** प्रक्रिया/मेमोरी/पथ प्रबंधक, ब्लॉक और सीरियल ड्राइवर, फ़ाइलसिस्टम, PCI सर्वर, सिस्टम लॉगर — ये सभी संसाधन प्रबंधक हैं जो संदेश भेजकर पहुँचे जाते हैं। कर्नेल में फ़ाइलसिस्टम नहीं है; इसमें एक प्रक्रिया की दूसरे से *फ़ाइलसिस्टम होने* के लिए पूछने की क्षमता है।

---

## 5. टास्कमैन और `TM_PRIV` विशेषाधिकार प्राप्त syscall

**`taskman`** QRV में उस चीज़ का नाम है जिसे QNX ने `procnto` कहा: संयुक्त **प्रक्रिया प्रबंधक, मेमोरी प्रबंधक, और पथ (नामस्थान) प्रबंधक**। एक क्लासिक QNX सिस्टम में यह कोड कर्नेल इमेज में समाहित होता है। QRV की बड़ी संरचनात्मक उपलब्धियों में से एक यह है कि **टास्कमैन अब उपयोगकर्ता मोड में चलता है** — यह एक सामान्य U-मोड प्रक्रिया है, विशेषाधिकार प्राप्त कर्नेल का हिस्सा नहीं।

यह एक स्पष्ट प्रश्न उठाता है: यदि टास्कमैन उपयोगकर्ता स्थान में रहता है, तो यह उन गहन विशेषाधिकार प्राप्त कार्यों को कैसे करता है जो एक प्रक्रिया और मेमोरी प्रबंधक को करने होते हैं — पेज टेबल में हेरफेर करना, भौतिक RAM आवंटित करना, एड्रेस स्पेस बनाना और नष्ट करना, सिग्नल और पल्स वितरित करना, प्रक्रियाओं को समाप्त करना?

उत्तर एक एकल, कसकर नियंत्रित प्रवेशद्वार है: **`__KER_TM_PRIV`**, syscall स्लॉट 2। यह *एकमात्र* द्वार है जिसके माध्यम से टास्कमैन कर्नेल-विशेषाधिकार प्राप्त संचालन तक पहुँचता है, और उस एक स्लॉट के पीछे **~98 उप-संचालनों** की एक डिस्पैच तालिका है — छोटे **कर्नेल एक्सटेंशन** ("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` (RISC-V इंस्ट्रक्शन-कैश कोहरेंस ऑपरेशन v0.43 में नया)

यह डिज़ाइन **विश्वसनीय कंप्यूटिंग बेस को छोटा रखता है** — वास्तविक कर्नेल न्यूनतम रहता है — जबकि टास्कमैन को वे विशेषाधिकार प्राप्त प्रिमिटिव देता है जिनकी उसे आवश्यकता है और **कुछ भी अतिरिक्त नहीं**। महत्वपूर्ण बात यह है कि कर्नेल हीप और अन्य कर्नेल आंतरिक भाग U-मोड के लिए अभिगम्य नहीं रहते (कर्नेल पेज `PTE_U=0` रखते हैं); टास्कमैन अपना काम कॉपी-इन/कॉपी-आउट kerexts के माध्यम से करता है, कभी भी किसी कच्चे कर्नेल पॉइंटर को सौंपकर नहीं। एनम `kernel/include/ker+tm/tm_kercalls.h` में रहता है; डिस्पैच तालिका `kernel/ker_tm_priv.c` में है।

---

## 6. बिग कर्नेल लॉक — और इसका निष्कासन

प्रारंभिक QRV — जैसे QNX पीढ़ी जिससे यह मल्टीप्रोसेसर सिस्टम पर आया था — ने कर्नेल को एक एकल **बिग कर्नेल लॉक (BKL)** से संरक्षित किया: एक वैश्विक `inkernel` शब्द जो एक समय में ठीक एक hart को कर्नेल में प्रवेश देता था। चाहे कितने भी CPU चल रहे हों, प्रत्येक सिस्टम कॉल और प्रत्येक टास्कमैन संदेश उस एक लॉक के माध्यम से क्रमबद्ध होता था। सही, सरल — और SMP स्केलेबिलिटी पर एक कठोर सीमा।

**v0.42 के अनुसार, BKL अब नहीं है।** यह रिलीज़ उम्मीदवारों की एक लंबी श्रृंखला की मुख्य बात थी और *The QRV Porting Story* के अध्याय 9–14 का विषय था। सिस्टम कॉल और टास्कमैन संदेश अब **हार्ट्स के बीच समवर्ती रूप से** चलते हैं, बारीक-दानेदार, प्रति-ऑब्जेक्ट लॉक के तहत:

- **प्रति-ऑब्जेक्ट लॉकिंग।** एक प्रति-`tChannel` लॉक और प्रति-`tConnect` लॉक संदेश कतारों की रक्षा करता है; एक प्रति-प्रक्रिया `vec_slock` थ्रेड वेक्टर की रक्षा करता है; एक प्रति-डिस्पैच `sched_slock` रन कतारों की रक्षा करता है; एक `alloc_slock` कर्नेल हीप की रक्षा करता है।
- **लॉक-मुक्त संदेश प्रेषण।** `MsgSend` / `MsgReceive` / `MsgReply` और `Sync*` परिवार **कोई वैश्विक लॉक नहीं लेते**। क्रॉस-hart रेंडेज़वस प्रति-थ्रेड ब्रिज बिट्स और हार्डवेयर मेमोरी फेंस द्वारा समन्वित होता है, न कि पारस्परिक बहिष्करण द्वारा।
- **SMR (RCU-समतुल्य) पुनःप्राप्ति।** थ्रेड्स, कनेक्शन और चैनल सुरक्षित-मेमोरी-रीक्लेमेशन के माध्यम से सेवानिवृत्त किए जाते हैं ताकि लॉक-मुक्त लुकअप कभी भी मुक्त किए गए ऑब्जेक्ट को डीरेफरेंस न करें।

QEMU `virt` पर `-smp 8` के साथ, कर्नेल विश्वसनीय रूप से `login:` प्रॉम्प्ट तक बूट होता है और बिना किसी रुकावट के 300-पुनरावृत्ति `pidin` तनाव लूप को बनाए रखता है।

---

## 7. स्टोरेज: `devb-nvme` और `fs-qrv`

माइक्रोकर्नेल मॉडल के अनुरूप, QRV में स्टोरेज **दो सहयोगी उपयोगकर्ता प्रक्रियाएँ** हैं, कर्नेल उपप्रणाली नहीं:

- **`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 ड्राइव दोनों पर एंड-टू-एंड चलता है।

8. उपयोगकर्ता स्थान

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) इतना महत्वपूर्ण है।

9. निर्माण और चलाना

टूलचेन```

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-आधारित है।

10. वास्तविक हार्डवेयर पर चलाना

QRV का द्वितीयक-लेकिन-गंभीर लक्ष्य SiFive Unmatched (FU740) है — एक वास्तविक RISC-V वर्कस्टेशन बोर्ड। एक माइक्रोकर्नेल जो QEMU पर साफ-सुथरा बूट होता है, उसे भौतिक सिलिकॉन पर भी साफ-सुथरा बूट कराने से ऐसे बगों का एक वर्ग सामने आया जो इम्यूलेशन बिल्कुल प्रदर्शित नहीं करता, और उनका पीछा करना ही हाल की रिलीज़ का अधिकांश हिस्सा है।

परिभाषित उदाहरण, v0.43 में ठीक किया गया: दो महीनों तक QRV QEMU पर त्रुटिहीन चला और हार्डवेयर पर विफल रहा। FU740 पर, कोई भी प्रोग्राम — pidin, lspci, कुछ भी — कुछ स्पॉन के बाद क्रैश हो जाता था, हर क्रैश पिछले से अलग होता था, प्रोग्राम काउंटर कचरे में भटकता था। इसका कारण मेमोरी भ्रष्टाचार बिल्कुल नहीं था, बल्कि instruction-cache असंगति थी: 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 विभाजन से परीक्षण प्रोग्राम माउंट करना और चलाना शामिल है।

11. समापन टिप्पणियाँ: एक मुक्त क्लोन क्यों महत्वपूर्ण है

QNX अब तक शिप किए गए सबसे प्रभावशाली माइक्रोकर्नेल डिज़ाइनों में से एक है। इसका send/receive/reply मॉडल ने सिस्टम इंजीनियरों की पीढ़ियों को सिखाया है कि एक स्वच्छ OS आर्किटेक्चर कैसा दिख सकता है। और फिर भी इसका प्रतीक कोड एक दशक से अधिक समय से एक अजीब सीमा में बिता रहा है: सामुदायिक लाइसेंस के तहत अध्ययन करने के लिए पर्याप्त दृश्य, लेकिन पुनर्वितरित करने, विकसित करने या चारों ओर एक जीवित पारिस्थितिकी तंत्र बनाने के लिए पर्याप्त मुक्त नहीं। इतना अच्छा डिज़ाइन केवल एक केवल-पढ़ने योग्य कलाकृति के रूप में संरक्षित रहने से बेहतर का हकदार है।

यही कारण है कि यह कार्य मौजूद है। QRV, स्पष्ट रूप से, एक संक्रमणकालीन वाहन है — आर्किटेक्चर को पोर्ट करके, उसे अलग करके और नए हार्डवेयर पर फिर से जोड़कर, कर्नेल लॉक को हटाकर और प्रक्रिया प्रबंधक को उपयोगकर्ता स्पेस में उठाकर और यह खोजकर कि कौन सी धारणाएँ भार वहन कर रही थीं, आर्किटेक्चर को गहराई से सीखने का एक तरीका। वास्तविक सिलिकॉन पर पीछा किया गया हर बग, 64-बिट स्वच्छ बनाने के लिए फिर से लिखा गया हर सबसिस्टम, ध्वस्त की गई हर मालिकाना सीमा, वह ज्ञान है जिसकी एक वास्तविक मुक्त कार्यान्वयन को आवश्यकता होगी।

क्योंकि दीर्घकालिक लक्ष्य किसी और के स्रोतों की पैच की गई प्रतिलिपि को हमेशा के लिए बनाए रखना नहीं है। यह एक पूरी तरह से मुक्त, शुरू से लिखा गया ऑपरेटिंग सिस्टम है जो QNX के इंटरफेस के साथ संगत है और इसके माइक्रोकर्नेल दर्शन के प्रति वफादार है, फिर भी मालिकाना कोड के लिए कुछ भी ऋणी नहीं है — एक ऐसा सिस्टम जिसका उपयोग, सिखाया, शिप किया और सुधारा जा सकता है बिना किसी से अनुमति मांगे। QRV वह तरीका है जिससे हम साबित करते हैं कि ऐसा सिस्टम न केवल संभव है बल्कि व्यावहारिक भी है, और हम इसे ठीक से बनाने का अनुभव कैसे अर्जित करते हैं।

यदि आप चाहते हैं कि ऐतिहासिक नींव स्वयं मुक्त हो जाए, तो PETITION.md में अपना नाम जोड़ें। और यदि आप देखना चाहते हैं कि एक आधुनिक, ईमानदारी से इंजीनियर किया गया माइक्रोकर्नेल अंदर से कैसा दिखता है — रेसिपी को क्लोन करें, obtain_proj.sh चलाएँ, और कोड पढ़ें।

QRV — 64-बिट हार्डवेयर के लिए QNX Neutrino 6.4 का अनुकूलन और पुन: कार्यान्वयन। क्रिसमस की पूर्व संध्या 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`	पुनर्लाइसेंसिंग याचिका।

qrv

सबसे लोकप्रिय