Maestro: Linux संगतता को लक्ष्य बनाने वाला Rust-आधारित कर्नेल

 (blog.lenot.re)
3 पॉइंट द्वारा GN⁺ 2024-01-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Maestro एक ऐसा प्रोजेक्ट है जिसका लक्ष्य Rust में एक नया Unix-परिवार का ऑपरेटिंग सिस्टम बनाना है, जो इतना हल्का हो कि उपयोगी रहे और इतना Linux-संगत हो कि रोज़मर्रा के इस्तेमाल के लायक बन सके
  • 2018 में स्कूल प्रोजेक्ट के रूप में शुरू हुआ, शुरुआत में इसे C भाषा में इम्प्लीमेंट किया गया था, लेकिन कोडबेस प्रबंधन की कठिनाइयों और कर्नेल डेवलपमेंट में सुरक्षा की ज़रूरतों के कारण Rust में स्थानांतरित किया गया
  • फिलहाल यह x86 32-बिट के लिए एक monolithic kernel है, और Linux के 437 system call में से 135 किसी हद तक implement किए जा चुके हैं, यानी लगभग 31%
  • बूट सिस्टम और डेमन मैनेजर Solfège, सिस्टम यूटिलिटीज, और पैकेज मैनेजर blimp भी साथ में बनाए जा रहे हैं, और musl, bash, तथा कुछ GNU coreutils भी चल रहे हैं
  • यह अभी बहुत शुरुआती चरण में है और अस्थिर है; परीक्षण मुख्यतः QEMU, VMWare, और VirtualBox में हुआ है, इसलिए महत्वपूर्ण डेटा वाली मशीन पर इसे इंस्टॉल न करना ही सुरक्षित है

Maestro के लक्ष्य और शुरुआत

  • Maestro एक Unix-परिवार का ऑपरेटिंग सिस्टम है जिसे शुरू से Rust में लिखा गया है
  • इसका लक्ष्य एक ऐसा सिस्टम बनाना है जो हल्का हो और रोज़मर्रा के उपयोग के लिए Linux के साथ पर्याप्त रूप से संगत हो
  • इसे इस उद्देश्य से शुरू किया गया कि सिस्टम को A से Z तक स्वयं समझा जा सके और अपनी पसंद के अनुसार customize किया जा सके

C से Rust में बदलने का कारण

  • पहला commit 2018 12 22 03:18 पर बनाया गया था, और प्रोजेक्ट की शुरुआत एक स्कूल असाइनमेंट के रूप में हुई थी
  • शुरुआती implementation लगभग डेढ़ साल तक C भाषा में चली, लेकिन कोडबेस को साफ़-सुथरा बनाए रखना कठिन होता गया
  • Rust में फिर से शुरू करने से मिले फायदे
    • पिछली गलतियों से सीखी बातों के आधार पर प्रोजेक्ट को शुरू से फिर से design किया जा सका
    • सिर्फ C में Linux-जैसा kernel दोबारा लिखने के बजाय कुछ नया आज़माया जा सका
    • Rust type system की वजह से memory safety की जिम्मेदारी का एक हिस्सा प्रोग्रामर की बजाय compiler संभाल सकता है

कर्नेल डेवलपमेंट में Rust कहाँ फायदेमंद रहा

  • कर्नेल डेवलपमेंट में debugging, सामान्य application की तुलना में कहीं अधिक कठिन है
    • documentation ढूँढना मुश्किल हो सकता है, और BIOS implementation में खुद खामियाँ हो सकती हैं
    • बूट के समय kernel पूरी memory तक पहुँच सकता है, इसलिए वह गलती से अपने ही code जैसी गलत जगहों पर भी लिख सकता है
    • memory leak ट्रैक करने के लिए valgrind जैसे टूल इस्तेमाल नहीं किए जा सकते
    • gdb को QEMU और VMWare के साथ इस्तेमाल किया जा सकता है, लेकिन emulator या virtual machine के हिसाब से kernel का व्यवहार बदल सकता है
    • VirtualBox जैसे कुछ environment gdb को support नहीं करते, और QEMU/VMWare का gdb support भी कुछ मामलों में अधूरा है; कभी-कभी gdb crash भी हो जाता है
  • इन समस्याओं को कम करने के लिए memory-safe language कर्नेल डेवलपमेंट में भी फायदेमंद होती है
  • Rust ने कर्नेल में कई safety guard जोड़ने में मदद की, और इसे प्रोजेक्ट के सबसे अच्छे निर्णयों में से एक माना गया

वर्तमान implementation स्थिति

  • Maestro फिलहाल एक monolithic kernel है और केवल x86 32-बिट architecture को support करता है
  • लेखन के समय implementation की स्थिति
    • Linux system call 437 में से 135 किसी हद तक implement किए गए हैं
    • system call implementation दर: {p:31}
    • सभी repositories को मिलाकर 615 files, 48,800 lines का code है
    • lines की गिनती cloc कमांड से की गई है
  • kernel के बाहर OS के components
    • Solfège: systemd से कुछ हद तक मिलता-जुलता लेकिन उससे हल्का boot system और daemon manager
    • maestro-utils: सिस्टम utility commands का संग्रह
    • blimp: package manager
    • अन्य components भी GitHub पर सार्वजनिक रूप से उपलब्ध हैं
  • जिन third-party software के चलने की पुष्टि हुई है
    • musl C standard library

    • bash

      • ls, cat, mkdir, rm, rmdir, uname, whoami आदि कुछ GNU coreutils commands
      • मूल neofetch Maestro को नहीं पहचानता, इसलिए patched neofetch version की आवश्यकता होती है

स्वयं परीक्षण करने के तरीके और सीमाएँ

  • यह OS अभी बहुत शुरुआती चरण में है और बेहद अस्थिर है
  • महत्वपूर्ण डेटा वाली मशीन पर इसे इंस्टॉल करने की सिफारिश नहीं की जाती
  • अब तक इसका परीक्षण मुख्यतः QEMU, VMWare, और VirtualBox में किया गया है
  • इंस्टॉलेशन के दो तरीके हैं
  • ISO में OS installer शामिल है और इसे QEMU, VMWare, VirtualBox आदि में चलाया जा सकता है
  • ISO चलाने के लिए पर्याप्त RAM चाहिए, और 1GB पर्याप्त है
    • क्योंकि इंस्टॉल किए जाने वाले package डिस्क पर नहीं बल्कि initramfs की RAM में store किए जाते हैं
    • फिलहाल OS USB stick या CD-ROM को सीधे पढ़ नहीं सकता, इसलिए bootloader पर निर्भर है

लेख में कवर किए जाने वाले विषय

  • उद्देश्य OS बनाने का tutorial लिखना नहीं है
  • OS development की बुनियादी सामग्री के लिए osdev.org और Philipp Oppermann’s blog की सिफारिश की गई है
  • आगे चलकर अधिक उन्नत विषयों, समस्या-समाधान की प्रक्रिया, और कंप्यूटर, ऑपरेटिंग सिस्टम, तथा इंटरनेट के अंदरूनी कामकाज पर चर्चा की जाएगी

आगे का development रोडमैप

  • प्राथमिकता कोडबेस की सफ़ाई और performance optimization है
  • चूँकि यह स्कूल प्रोजेक्ट के रूप में शुरू हुआ था, समयसीमा के कारण कुछ shortcuts लिए गए थे, और अब जमा हुए technical debt को चुकाना होगा
  • कुछ memory leak भी ठीक करने हैं, और performance optimization भविष्य के लेख का विषय बन सकता है
  • अगला बड़ा लक्ष्य package manager को OS के ऊपर पूरी तरह कार्यशील बनाना है
    • इसके लिए network support चाहिए, जिस पर अभी काम चल रहा है
    • shared library support भी आवश्यक है
    • shared library के लिए फ़ाइलों को सीधे memory में map करना होगा, लेकिन वर्तमान kernel का mmap system call implementation इसे support नहीं करता
  • उसके बाद gcc/g++, clang, rustc, make, Git, Vim जैसे प्रोग्राम को और आसानी से इंस्टॉल और टेस्ट किया जा सकेगा
  • अंतिम लक्ष्य Maestro के ऊपर ही kernel development workflow स्थापित करना है

कर्नेल की परिपक्वता बढ़ाने की विकास प्रक्रिया

  • development इस तरह आगे बढ़ता है कि किसी प्रोग्राम को kernel पर चलाया जाता है; अगर वह काम नहीं करता, तो समस्या पैदा करने वाले system call को ढूँढकर implement या fix किया जाता है
    • प्रोग्राम को kernel पर चलाना
    • अगर वह काम नहीं करता, तो system call output देखकर पहली समस्या पैदा करने वाली call को ढूँढना
    • अगर वह system call implement नहीं है या उसमें bug है, तो उसे implement या fix करना
    • फिर प्रोग्राम को दोबारा चलाना
  • जितने अधिक प्रोग्राम kernel पर सही तरह से चलेंगे, kernel उतना ही अधिक स्थिर और परिपक्व होता जाएगा

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

1 टिप्पणियां

 
GN⁺ 2024-01-04
Hacker News की राय

  • समर्थन के लिए सच में बहुत धन्यवाद, और मैंने इस प्रोजेक्ट में बहुत मेहनत लगाई है, इसलिए यह मेरे लिए बहुत मायने रखता है
    अभी वेबसाइट काफ़ी धीमी लग रही है या शायद डाउन है; उम्मीद से ज़्यादा traffic आ रहा है और DoS attack का भी शक है
    फिलहाल मैं काम पर हूँ, इसलिए तुरंत ध्यान देना मुश्किल है, लेकिन घर पहुँचकर इसे बेहतर चलाने की कोशिश करूँगा

    • लगता है यह HN के अपने Slashdot effect की वजह से हुआ DoS है
    • शानदार प्रोजेक्ट है, और यहाँ तक कि इसमें bash चल पाना एक बड़ा माइलस्टोन लगता है
      2010 में, जब Rust नहीं था, कॉलेज से निकलने के तुरंत बाद मैंने C में एक Unix-जैसे hobby OS पर थोड़ा काम किया था, और वह सच में बहुत मज़ेदार था
      ईर्ष्या होती है कि तुम यहाँ तक पहुँचने के लिए समय निकाल पाए
    • अच्छा होगा अगर वेबसाइट को mobile पर भी टेस्ट किया जाए
      navigation bar स्क्रीन का लगभग 33% हिस्सा घेर लेता है और हटाया नहीं जा सकता
      समझ नहीं आता लोग ऐसी चीज़ों को fixed क्यों रखते हैं और पढ़ने की कीमती जगह क्यों छीनते हैं। चाहें तो लगभग 300ms में ऊपर तक scroll किया जा सकता है

  • छोटा और बढ़िया प्रोजेक्ट है। Linux के system calls में से एक-तिहाई भी लागू नहीं किए गए हैं, फिर भी यह इतना boot हो जाता है—यह हैरान करने वाला है
    हालांकि जो चीज़ें छूटी हैं, उनके ज़्यादा जटिल होने की संभावना बड़ी है। उदाहरण के लिए TTY layer अभी काफ़ी basic स्तर की दिखती है, और इसे सही तरीके से बनाने में बहुत काम लगेगा
    इसलिए अगले 3 सालों में Maestro से Linux applications चलाने की उम्मीद करना मुश्किल है। Linux के हज़ारों drivers को ध्यान में न रखें, तब भी

    • बेहतरीन प्रोजेक्ट है, लेकिन वह अनुपात अपने-आप में बिल्कुल हैरान करने वाला नहीं है
      परिपक्व platforms कई scenarios support करने के लिए logic जोड़ते जाते हैं, और इसलिए ज़्यादातर लोगों को पूरे system के ज़्यादातर हिस्से की ज़रूरत नहीं पड़ती
      यह उस बात जैसा है कि “कोई भी Excel का 10% से ज़्यादा इस्तेमाल नहीं करता, लेकिन हर व्यक्ति का इस्तेमाल किया गया 10% अलग होता है”
      Excel functions का सिर्फ़ 30% लागू करके भी ऐसा engine बनाया जा सकता है जो दुनिया की 99% spreadsheets खोल सके। बस अगर पूर्ण document compatibility चाहिए, तो अभी लंबा रास्ता बाकी है
    • मेरा hobby OS किसी खास language VM के लिए बने FreeBSD-compatible kernel जैसा है। 424 में से 61 system calls support करता है, और काफ़ी समय से कोई छूटा हुआ call सामने नहीं आया
      कुछ system calls सिर्फ़ खास code paths में call होते हैं, या फिर नए kernel को target करने पर ही ज़रूरी होने वाले नए calls हो सकते हैं
      system calls बहुत हैं, और उनमें से कई काफ़ी उलझे हुए भी हैं। अगर पूरी तरह open replacement implementation बनानी हो तो अंततः ज़्यादातर को support करना पड़ेगा, लेकिन एक-तिहाई अच्छा शुरुआती बिंदु है
      [1] मैं VM को bare metal पर चलाना या VM की तरह boot करना चाहता था, और init=/path/to/the/vm जैसी चीज़ को छोड़ दें तो यह वहाँ तक सबसे कम मेहनत में पहुँचने का तरीका लगा। लेकिन वह तरीका मुझे वह असली चीज़ नहीं देता जो मैं चाहता हूँ: hardware drivers और TCP stack को VM language के अंदर रखना
    • क्या जल्द ही चल सकने वाली Linux applications का कोई subset हो सकता है? जैसे proxies, NFS, कुछ database servers, HTTP servers, firewalls वगैरह
      उपयोगी होने के लिए इसे Steam, LibreOffice, Firefox तक चलाने की ज़रूरत नहीं है, ऐसा मुझे लगता है। सामान्य server या microservice architecture के कई components अपेक्षाकृत सरल काम करते हैं, और सुरक्षित व सरल kernel से उन्हें काफ़ी बड़ा फायदा मिल सकता है

  • Kerla भी था, जो Rust में बना monolithic kernel था और Linux ABI compatibility को लक्ष्य बना रहा था। हालांकि लगता है वह कई सालों से inactive है
    [1] https://news.ycombinator.com/item?id=28986229

    • अभी भी जीवित Redox OS भी है: https://www.redox-os.org/
      यह microkernel design है, और शायद थोड़ा ज़्यादा mature होगा। MIT license है, इसलिए code share करने की गुंजाइश भी दिखती है

  • “सिर्फ़ Rust में बने होने की वजह से, कोई कुशल hacker कुछ ढूँढ पाता है या नहीं” यह देखने के लिए security/penetration testing/fuzzing करना मज़ेदार होगा

    • Rust सब कुछ नहीं रोकता। ऊपर से unsafe code भी बहुत है
      fuzzing tests या penetration tests किए जाएँ तो बहुत समस्याएँ सामने आएँगी, इसका मुझे 100% भरोसा है। अभी उस पर समय देने की गुंजाइश नहीं थी

  • लगता है यह वही काम है जिसे अब बंद हो चुके Kerla project में पहले ही आज़माया गया था

  • दिलचस्प प्रोजेक्ट लगता है। हालांकि C इस्तेमाल करने की कमियाँ और OS development की कठिनाइयाँ ज़्यादातर debugging के हिस्से में होती हैं, ऐसा मुझे लगता है
    Rust पर जाने से कुछ तरह की memory errors गायब हो गई होंगी, लेकिन क्या debugging अब भी दर्दनाक है? या पहले से कम होकर सहने लायक हो गई है, यह जानना चाहूँगा

    • memory और concurrency से जुड़ी बहुत समस्याएँ खत्म हो गई हैं
      debugging अब भी दर्दनाक है, लेकिन पहले से बहुत कम
      उदाहरण के लिए mutex इस्तेमाल करना भूल जाने की संभावना ज़्यादा नहीं रहती, क्योंकि compiler error देकर बता देता है
      फिर भी यह कोई जादुई समाधान नहीं है, और deadlock जैसी समस्याएँ अब भी रहती हैं। खासकर जब interrupts बीच में आ जाएँ
      उदाहरण के लिए, अगर mutex lock किया गया हो और interrupt आ जाए, तो उस mutex को lock करने वाला code interrupt खत्म होने तक रुक जाता है। लेकिन अगर interrupt handler उसी mutex को lock करने की कोशिश करे, तो deadlock बन जाता है, और type system इसमें मदद नहीं कर सकता
      समाधान यह है कि mutex lock रहने के दौरान interrupt handling को disable कर दिया जाए, लेकिन compiler इसे enforce नहीं कर सकता

  • थोड़ा अलग बात है, लेकिन author ने contribution video में जो Gource इस्तेमाल किया है, वह मुझे पसंद आया
    पहले मैंने इसे नहीं देखा था, लेकिन कुछ साल पहले ऐसा ही कुछ बनाने का idea आया था। लगता है सच में पूरी तरह नए ideas होते ही नहीं

  • खासकर सीखने के उद्देश्य से हो तो खुद kernel बनाना मुझे सच में बहुत अच्छा लगता है। kernel और OS को समग्र रूप से समझने के लिए आपने कौन-से resources इस्तेमाल किए, यह जानना चाहूँगा

  • हैरानी है कि Theseus OS का ज़िक्र नहीं आया। यह Rust में scratch से बनाया जा रहा OS है, और Rust compiler की memory safety guarantees का उपयोग करके ऐसी कई चीज़ें अपने-आप देता है जिन्हें पारंपरिक OS में बहुत सावधानी से जोड़ना पड़ता
    उदाहरण के लिए, single privilege level और single address space architecture होने के बावजूद यह safe है। OS का हर हिस्सा hot-pluggable है
    कमी यह है कि native code सब Rust में होना चाहिए, लेकिन पिछले साल WASM runtime implement किया गया था। 3 साल पहले की संबंधित thread:
    https://news.ycombinator.com/item?id=25741729

  • मुझे नहीं लगा था कि ft_penguin project उठाने जितना पागल कोई होगा। अभी भी पक्का नहीं कि वही नाम है या नहीं, लेकिन सच में बहुत अच्छा किया
    7 साल पहले जब मैं school में था, तो मुझे लगता था कि ज़रूरी समय की तुलना में reward सबसे खराब देने वाले projects में से यह एक है
    जानना चाहूँगा कि शुरुआत में इसे किसी दोस्त के साथ शुरू किया था या नहीं, और Rust में दोबारा लिखने से पहले यह कैसा था। यह भी कि क्या साथ-साथ दूसरे projects भी किए
    code देखकर मज़ेदार यादें ताज़ा हो गईं, और अब DevOps की नौकरी छोड़कर वही embedded या दूसरे low-level काम करना चाहता हूँ जो मूल रूप से करना चाहता था