करीब एक महीने में Unix clone लिखना

 (drewdevault.com)
3 पॉइंट द्वारा GN⁺ 2024-05-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यक्तिगत विश्राम-प्रोजेक्ट के रूप में शुरू किया गया Bunnix यह देखने का एक प्रयोग था कि x86_64 लक्ष्य वाले Unix-परिवार के operating system को लगभग एक महीने में कितनी दूर तक बनाया जा सकता है, और वास्तविक काम के हिसाब से इसमें 27 दिन लगे
  • kernel मुख्यतः Hare में लिखा गया है, और ext4 support के लिए lwext4 तथा kernel video terminal के लिए libvterm जैसे C components भी साथ में उपयोग किए गए हैं
  • यह legacy boot और EFI दोनों को support करता है और कुछ वास्तविक laptops पर test किया गया है, लेकिन USB support नहीं होने के कारण PS/2 keyboard या BIOS की PS/2 emulation की आवश्यकता होती है
  • user space में dash, Doom, gzip, less, mandoc, sbase, tcc, Vim 5.7 जैसे third-party software केंद्र में हैं, और libc, musl libc का Bunnix के लिए संशोधित रूप है
  • Bunnix काम करता है, लेकिन इसमें कई bugs हैं और यह अभी single-user system तक सीमित है; दीर्घकालीन maintenance से अधिक यह Helios के redesign और kernel design सुधारों की ओर ले जाने वाला एक प्रयोग है

Bunnix का दायरा और चलाना

  • Bunnix x86_64 लक्ष्य वाला Unix-परिवार operating system project है, जिसकी शुरुआत 21 अप्रैल 2024 को हुई
  • जिन दिनों वास्तव में काम नहीं हुआ उन्हें छोड़कर कुल 27 दिन लगाए गए
  • सीधे चलाने के लिए Bunnix 0.0.0 iso उपलब्ध है
  • qemu में ISO को निम्न command से boot किया जा सकता है
qemu-system-x86_64 -cdrom bunnix.iso -display sdl -serial stdio
  • ISO को USB stick पर लिखकर वास्तविक hardware पर भी boot किया जा सकता है
    • अधिकांश AMD64 machines पर चलने की संभावना है
    • ThinkPad X220 और Starlabs Starbook Mk IV पर test किया गया है
    • legacy boot और EFI दोनों को support करता है
  • इसे चलाने की सबसे बड़ी सीमा USB support का न होना है
    • PS/2 keyboard या BIOS की PS/2 emulation की आवश्यकता होती है
    • अधिकांश laptop keyboards PS/2 तरीके से जुड़े होते हैं
    • USB keyboard की PS/2 emulation का व्यवहार environment के अनुसार अलग हो सकता है
  • Doom port में key binding और exit behavior पर सीमाएँ हैं
    • WASD से movement
    • दायाँ Shift दबाकर fire
    • Space से door खोलना
    • game exit काम नहीं करता, इसलिए खेलने के बाद reboot करना पड़ता है

kernel संरचना और supported features

  • Bunnix kernel का अधिकांश हिस्सा Hare में लिखा गया है, और कुछ C components साथ में उपयोग किए गए हैं
    • ext4 filesystem support के लिए lwext4 का उपयोग
    • kernel video terminal के लिए libvterm का उपयोग
  • supported drivers मुख्य hardware और storage boot के लिए आवश्यक दायरे पर केंद्रित हैं
    • PCI legacy
    • AHCI block devices
    • GPT और MBR partition tables
    • PS/2 keyboard
    • platform serial ports
    • CMOS clock
    • bootloader द्वारा सेट किया गया framebuffer
    • ext4 और memfs filesystems
  • Unix-परिवार system के लिए जरूरी मूल kernel features भी शामिल हैं

    • virtual filesystem और devices

      • block devices, null, zero, full pseudo-devices, /dev/kbd, /dev/fb0, serial और video TTY, तथा /dev/tty control terminal के साथ /dev उपलब्ध है
      • अपेक्षाकृत पूरा terminal emulator और कुछ हद तक काम करने वाला termios support शामिल है

    • system calls और user model

      • clock_gettime, poll, openat, fork, exec, pipe, dup, dup2, ioctl आदि सहित लगभग 40 system calls supported हैं
      • वर्तमान में Bunnix एक single-user system है
      • Unix file modes और ownership को enforce नहीं करता
      • कुछ और दिनों के काम से इसे multi-user system बनाया जा सकता है

bootloader और user space

  • Bunnix में दो bootloaders शामिल हैं
    • legacy boot के लिए bootloader multiboot-compatible है और Hare में लिखा गया है
    • EFI के लिए bootloader C में लिखा गया है
  • दोनों bootloaders आवश्यकता होने पर kernel को ELF file और initramfs के रूप में load करते हैं
    • EFI bootloader initramfs decompression के लिए zlib शामिल करता है
    • multiboot-compatible bootloader decompression का काम संभाल लेता है
  • user space अधिकांशतः third-party sources से बना है
    • Colossal Cave Adventure advent
    • dash /bin/sh
    • Doom
    • gzip
    • less
    • lok /bin/awk
    • lolcat
    • mandoc
    • sbase core utils
    • tcc C compiler
    • Vim 5.7
  • libc, musl libc से लिया गया है और Bunnix की जरूरतों के अनुसार इसमें कई modifications किए गए हैं
  • curses library netbsd-curses पर आधारित है
  • system काम करता है, लेकिन इसमें कई bugs हैं और कुछ implementations जल्दीबाज़ी में बनाई गई हैं, इसलिए crashes के लिए तैयार रहना चाहिए

तेज़ implementation को संभव बनाने वाले कारक और चुनौतियाँ

  • Bunnix का कुछ code पिछले project Helios से आया है
    • इसमें GDT, IDT जैसे सामान्य CPU setup से संबंधित कुछ kernel code शामिल हैं
    • AHCI जैसे कुछ drivers भी Bunnix system के अनुसार अनुकूलित किए गए हैं
    • Helios का अनुभव न होता तो Bunnix को इतनी तेजी से बनाना कठिन होता
  • ext4 support और virtual terminal integration विशेष रूप से कठिन रहे
    • lwext4 और libvterm जैसी external dependencies लाई गईं
    • filesystem layer कई बार दोबारा लिखी गई और अभी भी bugs बचे हैं
    • openat और inode handling सहित Unix filesystem design को ठीक से लागू करने के लिए lwext4 के internals को और गहराई से देखना पड़ा
  • Hare project के भीतर Hare, assembly और C source को साथ link करने का अनुभव भी मिला
    • कुल मिलाकर यह अच्छी तरह काम किया, लेकिन ABI integration layer बनाने वाला हिस्सा असुविधाजनक था
    • C headers को Hare forward declaration modules में अपने-आप बदलने की जरूरत महसूस हुई
    • संबंधित काम hare-c में कुछ हद तक मौजूद है, लेकिन अभी और चाहिए
  • Vim port को लक्ष्य बनाने से terminal implementation की कठिनाई बढ़ गई
    • libvterm एक अच्छी terminal state machine library है, लेकिन documentation कम है
    • सही integration के लिए बहुत fine-tuning करनी पड़ी
    • इसे smooth चलाने के लिए performance optimization पर भी समय लगाया गया
  • scheduler वह क्षेत्र था जहाँ Helios-आधारित code का बड़ा हिस्सा छोड़कर दोबारा लिखा गया
    • Helios और Bunnix दोनों single-CPU systems हैं
    • Bunnix, Helios के विपरीत, kernel के भीतर context switching की अनुमति देता है
    • preemptive task switching भी kernel के माध्यम से अंदर-बाहर होती है
    • इस संरचना के लिए कई kernel stacks और अलग task switching approach की जरूरत होती है
    • पर्याप्त रूप से मजबूत scheduler होने पर disk reads या pipe(2) जैसे blocking operations को wait queue के साथ सरलता से implement किया जा सकता है
  • signals implementation Unix compatibility के लिए जरूरी थी
    • Helios Unix को लक्ष्य नहीं बनाता, इसलिए वह signals के बिना भी काम करता है
    • Bunnix में dash port के लिए मुख्यतः SIGCHLD के सही काम पर ध्यान दिया गया
    • अंतिम signals implementation बहुत बुनियादी स्तर की है

Helios की ओर ले जाने वाले design lessons

  • Bunnix एक monolithic kernel है और Helios, Unix नहीं बल्कि microkernel design है
  • filesystem के संदर्भ में caching के महत्व की पुष्टि हुई
    • Helios filesystem implementation को कई drivers और अलग processes में बाँटता है
    • केवल live objects को track करने के लिए भी filesystem layer में caching महत्वपूर्ण है
    • Helios redesign के समय filesystem code को refactor या फिर से लिखने का काम काफी बढ़ जाता है
  • driver approach monolithic kernel में स्वाभाविक रूप से अधिक सरल है
    • हालांकि ring 0 में बहुत कुछ रखने से पूरी तरह संतुष्टि नहीं है
    • Helios scheduler में monolithic design के control-flow तत्वों को आंशिक रूप से शामिल करने की गुंजाइश हो सकती है
  • memory management में bitmap allocator अपेक्षा से बेहतर काम करता दिखा
    • Helios में bitmap allocator से बचने की कोशिश की गई थी और memory management एक बड़ी असुविधा थी
    • Bunnix system की सामान्य pages के लिए एक सरल bitmap allocator का उपयोग करता है
    • अनुमान से इसका overhead इतना बड़ा नहीं था और यह बहुत अच्छी तरह काम करता है
  • लेखक का मानना है कि 30 दिनों के भीतर Bunnix बनाना microkernel design के साथ संभव नहीं होता
    • monolithic kernel implementation में कहीं अधिक सरल है
    • microkernel design के लाभ भी आकर्षक हैं, और बेहतर उत्तर hybrid kernel हो सकता है

project की स्थिति और बाकी संभावित सुधार

  • Bunnix ऐसा project कम है जिसमें आगे बहुत अधिक समय लगाया जाएगा; यह लगभग पूरा हो चुका एक art project अधिक है
    • कभी-कभी कुछ दिनों तक इस पर काम किया जा सकता है
    • community improvements के लिए public inbox पर patches स्वीकार किए जा सकते हैं
  • इसके बाद OS development की दिशा Bunnix से सीखे गए सबक के आधार पर Helios पर लौटकर बड़े redesign करने की है
  • संभावित improvement priorities इस प्रकार हैं
    • filesystem के लिए directory cache और overall caching improvements
    • ext4 bug fixes
    • procfs और top
    • file mmap
    • SIGSEGV जैसे अतिरिक्त signals
    • multi-user support
    • NVMe block devices
    • IDE block devices
    • ATAPI और ISO 9660 support
    • Intel HD audio support
    • network stack
    • base system के लिए Hare toolchain
    • self-hosting

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-25
Hacker News की राय

  • वाकई शानदार। यह बात याद आती है कि मूल Unix भी कथित तौर पर उन कुछ हफ्तों में बना था, जब Ritchie परिवार सास-ससुर से मिलने कैलिफ़ोर्निया छुट्टी पर गया था
    स्रोत: Brian W. Kernighan की UNIX: A History and a Memoir

    • यह महत्वपूर्ण है कि Unix लिखने से पहले भी वे लंबे समय से Multics पर काम कर चुके थे। अगर मेरी याद सही है, तो Unix उसका “सरल किया हुआ” संस्करण जैसा था; वह अचानक शून्य से नहीं निकला था
    • शायद आप Ken Thompson की बात कर रहे हैं। YouTube इंटरव्यू ढूंढने में आलस आ रहा है, लेकिन मुझे याद है कि उन्होंने कई बार कुछ ऐसा बताया था कि disk driver, कुछ programs और दूसरे components पहले से मौजूद थे, और पत्नी के यात्रा पर जाने के दौरान उन्हें लगा कि खाली हिस्सों को भरकर इसे एक पूरा operating system बनाने का समय मिल जाएगा
    • Unix खुद बनने में काफ़ी समय लगा मानना चाहिए। अगर V7 को “ठीक से पूरा हुआ Unix” मानें, तो इसमें कई साल लगे; और पहला version, मसलन, बस file system ही था
    • मेरी जानकारी में यह कहानी उन छूटे हुए 3 programs के बारे में थी, जिनमें से एक text editor था
      अभी याद धुंधली है, इसलिए जांचना पड़ेगा
    • लगता है आपने Dennis Ritchie और Ken Thompson को मिला दिया है

  • “मैंने आखिरकार सीखा कि signals ऊपर से नीचे तक कैसे काम करते हैं, और यह सचमुच बदसूरत है। मुझे हमेशा लगा है कि Unix design के सबसे कमजोर हिस्सों में से एक यही है, और इस project ने मेरी राय नहीं बदली” — इस हिस्से पर अगर और विस्तार से कोई material हो तो देखना चाहूंगा। अगर HN users या लेखक कुछ जानते हों तो जानना चाहूंगा

    • अगर अभी तक नहीं देखा है, तो मैं Stevens की Advanced Programming in the Unix Environment से शुरू करूंगा
      https://www.amazon.com/Advanced-Programming-UNIX-Environment...
      user space में signals और processes सहित Unix API से निपटने की जिम्मेदारी
      kernel के अंदर signals implement करना हो तो क्या recommend करूं, यह ठीक से नहीं जानता, लेकिन शायद https://pdos.csail.mit.edu/6.828/2012/xv6.html याद आता है
      Unix कैसे काम करता है, इसे self-contained examples के साथ साफ़ और व्यवस्थित ढंग से समझाने वाली किताब पढ़ना सचमुच ताज़गी भरा है। C नहीं आती तो बाधा हो सकती है, लेकिन blog post पढ़ते समय भी यही बात लागू होती है
      मुझे नहीं लगता कि समान स्तर की जानकारी web पर कहीं मौजूद है। मेरे blog पर भी Unix से जुड़ी बहुत-सी ऐसी छोटी-मोटी जानकारी है जिसे लोग अब भी पढ़ते हैं, लेकिन वह उसी स्तर की नहीं है
      Unix signals समझने के लिए blog posts, Google, LLM से approach करना उन topics में से है जो बेहद inefficient है। second-hand भी इसे “सस्ता” कहना मुश्किल है, लेकिन जानकारी की value के कारण इसका price ऊंचा बना रहता है, और कामकाजी programmer के लिए यह अपेक्षाकृत सस्ता ही है
    • signals asynchronous input/output/system calls और inter-process communication के मिलन-बिंदु पर हैं। async और IPC भी मूल Unix design की कमजोरियां हैं और शुरू से मौजूद elements नहीं थे
      signals design में async IPC को जबरन चिपकाने की awkward कोशिश हैं, इसलिए race conditions के प्रति संवेदनशील हैं। signal handling के दौरान फिर signal मिल जाए तो क्या हो, या process system call के बीच में हो तब signal के साथ क्या किया जाए—ये सब अस्पष्ट है। delay करना है, queue में डालना है, या system call से बाहर निकालना है, यह तय करना पड़ता है
      अगर सभी system calls asynchronous हों, तो कई आधुनिक operating systems जिन design principles को अपनाते हैं, उसी तरह यह पहलू हल हो जाता है। IPC में reliable channel जैसी कोई system हो, तो सिर्फ signals ही नहीं, बल्कि और refined asynchronous inter-process communication या procedure calls भी implement किए जा सकते हैं
    • लगता है Unix signals बहुत-सी अलग-अलग concepts का बोझ उठा रहे हैं, इसलिए कुछ लोग उन्हें नापसंद करते हैं
      SIGSTOP/SIGCONT/SIGKILL असल में process को signal भेजने से ज़्यादा pause, resume, terminate जैसे process control करते हैं
      SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU जैसे simple asynchronous messages का config फिर से पढ़ने आदि के लिए दुरुपयोग होता है, और daemonization के लिए nohup जैसी hacky workaround जुड़ जाती है। gunicorn आखिरी दो का उपयोग dynamic scale-up/scale-down के लिए भी करता है। इसी category में SIGWINCH जैसा अजीब तरह से specific signal भी है
      फिर SIGILL, SIGSEGV, SIGFPE जैसे signals हैं, जो invalid instruction, segmentation violation, floating-point exception बताते हैं। SIGSYS जैसे signals भी हैं जिनके लिए यह साफ़ नहीं कि उन्हें शुरुआत से asynchronous रखना अच्छा है या नहीं
      दूसरे approaches में भी trade-offs हैं। Windows में events, SEH, CTRL+C/CTRL+BREAK/termination handling routines, IOCP, callbacks वगैरह हैं, और Plan 9 के notes strings हैं, इसलिए दूसरे process को arbitrary data भेज पाना अच्छी बात है; लेकिन process control के लिए भी वही mechanism इस्तेमाल करना *nix जैसी ही कमी रखता है, बस numbers की जगह strings हैं
    • “signalfd is useless” अच्छा लेख है: https://ldpreload.com/blog/signalfd-is-useless
      यह Unix signals की समस्या पर बात करता है, और यह भी समझाता है कि Linux ने इसे हल करने के लिए जो signalfd बनाया वह ठीक से काम क्यों नहीं करता
    • portable applications लिखते समय BSD और SYSV की signal handling में अंतर समस्या बना था
      https://pubs.opengroup.org/onlinepubs/009604499/functions/bs...
      यह भी महत्वपूर्ण है कि signal handler के अंदर का code reentrant होना चाहिए। “non-reentrant functions को आम तौर पर signal handler से call करना सुरक्षित नहीं होता”
      https://man7.org/linux/man-pages/man7/signal-safety.7.html

  • मुझे Hare में दिलचस्पी थी, लेकिन यह FAQ आइटम देखकर यह बेहद आत्मघाती policy लगी: https://harelang.org/documentation/faq.html#will-hare-suppor...
    मूल रूप से, मैं इस बात का समर्थन करता हूँ कि developer अपनी पसंद का license इस्तेमाल करे, अपनी पसंद के operating system को target करे, और अपनी पसंद का code लिखे
    लेकिन इससे यह specific policy अच्छा idea नहीं बन जाती। free software philosophy के सबसे चरम या सिद्धांतवादी समूह माने जाने वाले FSF तक Windows और POSIX को support करते हैं। शिकायत करते हुए उसे Woe32 कहा जा सकता है, लेकिन Stallman काफी convincingly कहते रहे हैं कि free software projects को proprietary systems पर भी चलने लायक बनाना, proprietary software के बिना दुनिया की लड़ाई में ज्यादा मददगार है
    library code को MPL के तहत license किया गया है, इसलिए सिर्फ Hare इस्तेमाल करने से आप किसी specific license से बंधते नहीं। लेकिन उस भाषा की उम्र क्या होगी जो desktop के 95% से ज्यादा हिस्से से कहती है, “support नहीं, forum में सवाल मत पूछो, यहाँ मत आओ” — इस पर संदेह है
    विडंबना यह है कि Google पर “harelang repo” खोजने पर पहला result unofficial macOS port है, और असली SourceHut repository पहले page पर दिखती ही नहीं
    भाषाएँ या तो snowball की तरह बढ़ती हैं या गायब हो जाती हैं। मैं अभी यह Mac पर लिख रहा हूँ, लेकिन चाहूँ तो अभी तुरंत Linux machine भी इस्तेमाल कर सकता हूँ। फिर मैं ऐसी भाषा क्यों सीखूँ जो developers पर ऐसा purity test थोपती है जो FSF तक नहीं करता? open source और free software का बड़ा हिस्सा Mac पर लिखा जाता है, और उम्मीद से कहीं ज्यादा हिस्सा Windows पर भी लिखा जाता है
    मेरी नजर में Hare को Odin या Zig से अलग करने वाली चीज यही purity और exclusion वाला रवैया है। मजेदार hacking और सफलता की शुभकामनाएँ, लेकिन बाद वाली बात को लेकर मैं pessimistic हूँ

    • एक तरफ, authors जो हासिल करना चाहते हैं उस पर टिके रहते हैं और हर demand नहीं मानते — इसका सम्मान किया जा सकता है
      दूसरी तरफ, FAQ में भौंहें चढ़ाने वाली बात सिर्फ यही नहीं है
      “कोई package manager नहीं है, और shared value के तौर पर code reuse को कम encourage किया जाता है”
      “qbe, LLVM से धीमा code generate करता है, और performance मिलते-जुलते LLVM-generated code की तुलना में runtime performance के 25–75% range में है”
      “क्या Hare में multithreading इस्तेमाल कर सकते हैं? शायद नहीं”
      “तो क्या hash table खुद implement करनी होगी? हाँ। hash table एक common data structure है जिसे कई Hare programs को scratch से implement करना होगा”
      फिलहाल यह साफ है कि यह भाषा mass adoption को target करके design नहीं की गई है। ठीक है, और कम से कम वे इस बात को ईमानदारी से बताते हैं
    • “थोपना” शब्द से मैं सहमत नहीं हूँ। अगर कोई free में कुछ कर रहा है, तो जब तक वह malicious नहीं है, उसे किसी specific तरीके से करने की कोई बाध्यता नहीं है
      opinion व्यक्त करने की आजादी है, लेकिन जब developers पहले ही guidelines तय कर चुके हों, तो ऐसी आलोचना मुझे constructive नहीं लगती
    • लगता है आपकी और Hare पक्ष की success की definition अलग है। “भाषाएँ या तो snowball की तरह बढ़ती हैं या गायब हो जाती हैं” वाली बात भी, rockstar-level popularity न होने के बावजूद दशकों तक लगातार आगे बढ़ती रहीं कई भाषाओं को काफी कमतर आँकती लगती है
      हर band को सुनने लायक होने के लिए Billboard chart पर होना जरूरी नहीं है
    • इसका मतलब है कि वे officially Windows या macOS को support नहीं करेंगे। अगर चाहें तो दूसरे projects port करने की कोशिश कर सकते हैं, है ना? intended support level को ईमानदारी से बताना अच्छा लगता है
      जिन operating systems का developers खुद इस्तेमाल नहीं करते, उन्हें support करना बड़ी demand है
    • “भाषाएँ या तो snowball की तरह बढ़ती हैं या गायब हो जाती हैं” वाली बात सच नहीं है और naive expression है
      कुल मिलाकर बहुत popular न होते हुए भी, कई भाषाएँ हैं जो मजबूत niche में फलती-फूलती हैं और अहम भूमिका निभाती हैं

  • impressive, बहुत शानदार और inspiring। “X दिनों में कुछ impressive बनाना” जैसे examples के लिए कई सालों का experience और talent चाहिए होता है

    • आजकल की तुलना में, मुझे internationalized string वाले एक button text को बदलने में लगभग एक हफ्ता लग गया था
      English string को catalog में डालना, कई tests update करना, local system पर tests चलाना, changes को staging cluster पर डालना, unexpected test failures ठीक करना, production में डालना, translation team से कई भाषाओं में translation मांगना, और documentation भी update करना पड़ा था
    • 12 साल से भी ज्यादा पहले सिर्फ Z80 assembly में लिखे गए KnightOS के creator भी हैं
      https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...
    • Drew smart हैं और timeline भी छोटी थी, लेकिन मुझे लगता है कि उन्हें बस pedestal पर चढ़ाकर देखना गलत perspective है। UNIX clone बनाना ज्यादातर universities में common undergraduate project है
      उसे polished चीज में expand करने के लिए special genius से ज्यादा perseverance चाहिए
    • साथ ही उनका पिछला kernel implementation Helios भी था, जिसने lowest-level code का काफी हिस्सा दिया। achievement को कम करके दिखाने का इरादा नहीं है, लेकिन DD ने काफी openly कहा है कि इस project की speed का बड़ा हिस्सा इस बात पर निर्भर था कि उन्होंने पहले Helios बनाया था और उसका code reuse किया
    • Helios था, इसलिए कुछ missing parts को integrate करने जैसा ही था

  • Mastodon पर लगभग रोज आने वाले updates देखना वाकई शानदार था। एक skilled व्यक्ति को complex software को थोड़ा-थोड़ा fit करते हुए देखने को मिला

  • code यहाँ है: https://git.sr.ht/~sircmpwn/bunnix/tree/master
    GPLv3 license है

  • user space ज्यादातर third-party source से assemble किया गया है
    ISO पर click करने पर 60MB download दिखा तो पहले हैरानी हुई, लेकिन वजह समझ आ गई
    तुलना के लिए, Linux 0.01 71KB download था, लेकिन उसमें सिर्फ kernel source था

  • Hare एक दिलचस्प भाषा लगती है
    हालांकि इस multicore दौर में नीचे दी गई सीमा इसके adoption को सीमित कर सकती है
    FAQ https://harelang.org/documentation/faq.html के अनुसार, Hare में multithreading इस्तेमाल कर सकते हैं या नहीं, इस सवाल का जवाब “शायद नहीं” है
    I/O operations को multiplex करने के लिए event loop, और जब CPU resources को parallel में इस्तेमाल करना हो तो shared memory के साथ multiple processes की सिफारिश की गई है
    सख्ती से कहें तो Hare program में threads बनाए जा सकते हैं। libc से link करके pthreads इस्तेमाल कर सकते हैं या clone(2) system call को सीधे इस्तेमाल कर सकते हैं। Helios जैसे Hare में implement किए गए operating systems आमतौर पर multithreading implement करते हैं
    लेकिन upstream standard library reentrancy guarantee नहीं देती, इसलिए अपने पैर पर कुल्हाड़ी न मारें, इसकी पूरी जिम्मेदारी आपकी ही है

    • “अगर CPU resources को parallel में इस्तेमाल करना हो तो shared memory के साथ multiple processes” असल में काफी powerful है
      व्यक्तिगत रूप से मैं ज्यादातर use cases के लिए इसी तरीके को पसंद करता/करती हूं, क्योंकि यह data race की संभावना को सिर्फ shared memory region तक सीमित कर देता है। data race के नजरिए से यह memory के “unsafe block” जैसा लगता है
    • अगर upstream standard library reentrancy guarantee नहीं देती, तो सिर्फ multithreading ही नहीं बल्कि interrupts के अंदर इस्तेमाल भी बाहर हो जाता है। “system programming language” के हिसाब से मुझे यह काफी बड़ी limitation लगती है
    • अच्छा होता अगर closures होते

  • यह “Linux System Call Table – Chromiumos” https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777 में आई बात है
    google/syzkalleR
    Fuschia / Zircon system calls: https://fuchsia.dev/fuchsia-src/reference/syscalls