Linux kernel development के लिए Rust भाषा की नई सुविधाएँ

 (lwn.net)
13 पॉइंट द्वारा GN⁺ 2025-10-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust for Linux प्रोजेक्ट kernel development के लिए ज़रूरी core language features को आगे बढ़ा रहा है और Rust भाषा के विकास में भी योगदान दे रहा है
  • Field Projection, In-place Initialization, और Arbitrary Self Types ये तीन मुख्य सुविधाएँ हैं
  • ये सुविधाएँ smart pointers, pinned memory (Pin), RCU जैसी kernel-विशिष्ट संरचनाओं को Rust में अधिक स्वाभाविक तरीके से व्यक्त करने में मदद करती हैं
  • Rust टीम design stability को बहुत महत्व देती है, इसलिए विकास की रफ्तार धीमी है, लेकिन Linux kernel जैसा स्पष्ट लक्ष्य होने से development focus बढ़ा है
  • kernel के बाहर के Rust ecosystem पर भी इन बदलावों का असर पड़ेगा, और smart pointer handling तथा code simplification में बड़ी मदद मिलने की संभावना है

Rust भाषा सुधार और Linux kernel की भूमिका

  • Rust भाषा में नई सुविधाओं का विकास धीमा होने की वजह खराब design को भाषा में स्थायी रूप से न बैठा देने की सावधानी और "alignment in attention" की समस्या है
    • Rust प्रोजेक्ट volunteers द्वारा चलाया जाता है, इसलिए अगर किसी खास सुविधा पर ध्यान केंद्रित करने वाले लोग न हों तो development धीमा पड़ जाता है
  • Rust for Linux प्रोजेक्ट बहुत लोगों के लिए उत्साह का विषय है, इसलिए यह kernel के लिए ज़रूरी कुछ मुख्य features पर प्रयासों को केंद्रित करने में मदद करता है
  • Rust language team के co-lead Tyler Mandry ने Kangrejos 2025 में Rust की आने वाली language features पेश करते हुए कहा कि Linux kernel प्रोजेक्ट ने Rust के विकास में catalyst की भूमिका निभाई है
    • मुख्य सुविधाएँ: Field Projection, In-place Initialization, Arbitrary Self Types
    • kernel development ने वास्तविक use cases और तकनीकी आवश्यकताओं को स्पष्ट रूप से सामने रखा, जिससे Rust की language design दिशा को ठोस रूप मिला
    • सबसे ऊँची प्राथमिकता kernel bindings में पहले से इस्तेमाल हो रही unstable features को standardize करना है

Field Projection

  • यह struct pointer से किसी खास field pointer को निकालने की सुविधा है, और C के &(r->field) अभिव्यक्ति को Rust में सामान्यीकृत करने की कोशिश है
  • पहले यह केवल references (&) और *pointers (mut) पर ही संभव था, लेकिन user-defined smart pointers में इसकी सीमा थी
  • Rust for Linux इसे बढ़ाकर सभी pointer types में एक ही syntax से field access संभव बनाना चाहता है
  • खासकर Pin type (जिसमें struct को move नहीं किया जा सकता) के मामले में, field projection के समय इसे Pin<&mut Field> या &mut Field में अपने-आप बदलने के लिए design किया गया है
  • इस सुविधा के लागू होने पर RCU(Read-Copy-Update) pattern को Rust में सुरक्षित तरीके से support किया जा सकेगा, जिससे lock के बिना भी high-performance data access संभव होगा
  • इस पर अभी GitHub के tracking issue में चर्चा चल रही है, और Debian 14(2027) से पहले इसे stable करने का लक्ष्य है

Arbitrary Self Types

  • यह smart pointers को स्वीकार करने वाली method definitions को संभव बनाती है
  • पहले केवल fn method(&self) जैसे रूप समर्थित थे, लेकिन अब fn method(self: Pin<&mut MyStruct>) जैसा रूप भी संभव हो रहा है
  • kernel में Arc, Pin, Mutex जैसे कई pointer wrappers इस्तेमाल होते हैं, इसलिए यह सुविधा अनिवार्य है
  • implementation के दौरान Deref trait के साथ टकराव की समस्या थी, लेकिन नए Receiver trait को जोड़कर इसे हल किया जा रहा है
  • Receiver यह स्पष्ट करता है कि कोई pointer arbitrary self type के रूप में इस्तेमाल किया जा सकता है
  • kernel development में इससे pointer chain calls को संक्षिप्त रखा जा सकता है
  • Ding, Crater tool का उपयोग करके मौजूदा Rust packages के साथ compatibility की जाँच कर रहे हैं, और उन्होंने 1 साल के भीतर stabilization की संभावना बताई है

In-place Initialization

  • यह kernel में इस्तेमाल हो रहे pin_init!() macro को भाषा स्तर पर support देने वाली सुविधा है
  • इसमें object को बनाने के बाद move किए बिना सीधे memory में initialize किया जाता है, जो Pin structs, Future, dyn traits आदि के लिए उपयोगी है
  • इस पर तीन प्रस्ताव साथ-साथ चर्चा में हैं
    • init keyword approach: बहुत कम syntax जोड़कर मौजूदा PinInit trait का उपयोग
    • &out reference approach: C के out pointer की तरह write-only reference जोड़ना, जिससे field-level initialization संभव हो
    • C++ style optimization approach: जिस object को तुरंत heap में जाना है, उसे शुरू से ही सीधे heap में बनाना
  • अंत में PinInit और out-reference दोनों approaches को प्रयोगात्मक रूप से आज़माकर वास्तविक usability की जाँच करने की योजना है
  • इस सुविधा के आने पर सिर्फ kernel ही नहीं, बल्कि asynchronous Rust code की समग्र संरचना को सरल बनाने में भी मदद मिलने की उम्मीद है

Rust for Linux का Rust पर प्रभाव

  • Linux kernel, Rust भाषा के विकास में एक व्यावहारिक testbed की भूमिका निभा रहा है
  • ये तीनों सुविधाएँ smart pointers, pinned memory, concurrency structures जैसी kernel-विशिष्ट आवश्यकताओं से शुरू हुई हैं,
    लेकिन अंततः सामान्य Rust developers को भी इनका लाभ मिलेगा
  • इन बदलावों को kernel और language development के बीच positive feedback loop के उदाहरण के रूप में देखा जा रहा है

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

2 टिप्पणियां

 
GN⁺ 2025-10-17
Hacker News की राय

  • Rust की lightweight clones फीचर के लिए RFC दस्तावेज़ को पढ़कर समझने में मुझे थोड़ा समय लगा। शुरुआत में यह फीचर काफी दिलचस्प लगा, लेकिन आखिर में फिर से यही महसूस हुआ कि Rust सीखने में काफ़ी जटिल भाषा है। मेरे जैसे व्यक्ति के लिए, जिसने Rust या C++ को ठीक से नहीं सीखा है, यह ऐसा लगता है मानो modern C++ के सारे concepts और features, Haskell के तत्वों के साथ मिल गए हों। फिर भी जब लोगों को Rust से बहुत-सी उपयोगी चीज़ें बनाते देखता हूँ, तो लगता है कि इसमें कुछ तो सही है। इसलिए मैं जल्द ही फिर से Rust को गंभीरता से आज़माने का सोच रहा हूँ। संबंधित RFC लिंक

    • मेरे अनुभव में C++, Rust से कहीं ज़्यादा जटिल है। उदाहरण के लिए initialization के ही 8 तरीके हैं, values के types भी xvalues समेत 5 तरह के हैं, formatting और naming conventions भी एकसमान नहीं हैं, rule of 5, exception handling, move assignment करते समय हमेशा this != other चेक करना, perfect forwarding, SFINAE, trait के विकल्पों की समस्या जैसी बहुत-सी जटिल बातें हैं। C++ को ठीक से इस्तेमाल करने के लिए standard के ऊपर बनी उन conventions को भी सीखना पड़ता है जो safe और fast coding के लिए उपयोग होती हैं, और exception handling जैसी चीज़ों में अक्सर तरीके आपस में टकराते हैं या non-ideal तरीके चुनने पड़ते हैं

    • Rust समुदाय में इस lightweight clones प्रस्ताव को लेकर माहौल धीरे-धीरे नकारात्मक होता जा रहा है। वजह है कि यह बहुत जटिल है। design direction पर Rust का आधिकारिक दस्तावेज़ भी बताता है कि complexity सबसे बड़ी रुकावट है। Rust के किसी प्रस्ताव में हर फीचर का बहुत simple होना ज़रूरी नहीं है, लेकिन lightweight clone सिर्फ़ पहले से संभव काम को थोड़ा आसान बनाता है, और अगर लोग उसे आसानी से समझ ही नहीं पाते, तो वह समस्या है

    • Rust दूर से देखने पर बहुत विशाल लगता है, लेकिन असल में कोडिंग करते हुए जल्दी आदत हो जाती है। उदाहरण के लिए शुरुआत में मुझे lifetime का concept बिल्कुल समझ नहीं आया, इसलिए मैं सिर्फ़ Rc<> के साथ कोड लिखता था। बेसिक्स सीखने के बाद जब lifetime को फिर से पढ़ा, तो वह बहुत आसान लगा। सच कहें तो ज़्यादातर users को lightweight clones जैसी सुविधाओं की चिंता करने की ज़रूरत ही नहीं पड़ती

    • C की तुलना में यह बहुत जटिल है, लेकिन C++ की तुलना में काफ़ी सरल भाषा है। कोड समझने के लिए documentation या reference को खंगालने की ज़रूरत लगभग नहीं पड़ती। Rust एक तरह से बहुत संतुलित जगह पर है: "इतनी जटिल नहीं कि दिमाग़ खराब हो जाए, और इतनी सरल भी नहीं कि कोड ही जटिल बन जाए।" ऊपर से by default कोड में correctness भी रहती है

    • Rust की जटिलता C++ की तरह गलती से गलत इस्तेमाल होने वाली नहीं है। और अगर clippy इस्तेमाल करें, तो वह और ज़्यादा idiomatic code में अपने-आप बदलने की सलाह देता है, इसलिए lightweight clones जैसे नए features को सीधे न जानते हों तब भी सुझाव मिल जाता है। ज़्यादातर चीज़ें clippy के --fix option से आसानी से लागू की जा सकती हैं। यही वह बात है जो इसे C++ से decisively अलग बनाती है; C++ में जो features आप इस्तेमाल नहीं भी करते, वे जमा होते रहते हैं या चीज़ें अनावश्यक रूप से ज़रूरत से ज़्यादा जटिल लिखी जाती हैं, और इस तरह complexity बढ़ती ही रहती है

  • मैंने सुना था कि Rust for Linux प्रोजेक्ट ने Rust को बहुत मदद दी है, इसलिए जिज्ञासा में kernel tree में *.rs फाइलें ढूँढकर देखा। देखने पर लगा कि rust फ़ोल्डर के नीचे API compatibility layer है, और kernel tree में सिर्फ़ कुछ proof-of-concept drivers हैं जो पुराने drivers का simple rewrite हैं (अधूरे Nvidia driver को छोड़कर), और व्यावहारिक रूप से ऐसा कुछ नहीं दिखा जो वास्तव में उपयोग में हो। Android binder का Rust rewrite भी लगभग बस पड़ा हुआ-सा लगा। कुल मिलाकर यह एक छोटा-सा प्रयोगात्मक प्रोजेक्ट जैसा लगा, और लगा कि दुनिया के सबसे महत्वपूर्ण software के source tree में ऐसी language co-development experiment करने की ज़रूरत है भी या नहीं। शायद Redox जैसे ज़्यादा experimental OS में यह करना बेहतर होता

    • Apple silicon के लिए GPU driver Rust में लिखा गया है, और उसके लेखक ने खुद कहा है कि अगर इसे C में लिखा होता तो यह बहुत ज़्यादा कठिन होता। अभी यह upstream में नहीं गया है, लेकिन उनका कहना है, "जब आप कोई जटिल kernel driver नया बनाते हैं, तो race condition, memory leak, use-after-free जैसी हर तरह की समस्या सामने आती है, लेकिन Rust में लिखने पर ऐसी समस्याएँ लगभग नहीं आईं और यह स्थिर रूप से चला। Safety features की वजह से भरोसा होता है कि driver thread-safe और memory-safe है, और design भी स्वाभाविक रूप से अच्छी दिशा में जाता है। यही Rust का जादू है।" लेखक के अनुभव का लिंक और kernel tree में ऐसे experiments करने चाहिए या नहीं, इस सवाल पर भी Torvalds ने असहमति जताई थी, ऐसा बताया गया

    • "Android binder का Rust rewrite बस पड़ा हुआ है" यह बात सही नहीं है। इस प्रोजेक्ट की अभी की योजना C implementation को पूरी तरह replace करने की है। संबंधित लेख M-series Apple hardware के लिए मुख्य drivers भी Rust में लिखे गए हैं, और वे सिर्फ़ rewrite या proof of concept नहीं हैं

    • जटिल drivers बनाने के लिए पहले interface layer चाहिए। RfL प्रोजेक्ट upstream में वही infrastructure layer जोड़ने का काम कर रहा है, और वही बुनियाद बनेगी जिसके ऊपर जटिल drivers लिखे जा सकेंगे। Redhat में nova, Asahi में Apple GPU, और Collabora में ARM Mali के लिए काम चल रहा है। अगर तीन GPU drivers भी जटिल drivers नहीं माने जाएँ, तो फिर जटिल driver किसे कहेंगे, समझना मुश्किल है

    • Rust binder rewrite बस पड़ा हुआ है, इस दावे के जवाब में, Linus tree के commit messages देखें तो पता चलता है कि यह काफ़ी परिपक्व स्थिति में है। Rust binder ने Android Open Source Project के binder tests पूरे पास कर लिए हैं, और कई apps व features बिना किसी खास समस्या के काम करते हैं। Cuttlefish emulator और Pixel 6 Pro पर भी boot और app execution में कोई समस्या नहीं है। मौजूदा functionality भी C binder जैसी ही है, सिर्फ़ कुछ debugging features बचे हैं जो जल्द जोड़े जाने वाले हैं। और Rust for Linux प्रोजेक्ट भले शुरुआत में kernel tree के बाहर शुरू हुआ हो, लेकिन असली integration का प्रयोग आखिर tree के अंदर ही करना पड़ता है

    • इस प्रोजेक्ट का उद्देश्य language development का co-experiment नहीं है, बल्कि Linux kernel development में Rust का इस्तेमाल करना है। Core developers खुद Rust इस्तेमाल करना चाहते थे, इसलिए उन्होंने यह प्रोजेक्ट शुरू किया। Software इतना महत्वपूर्ण है कि काम बहुत सावधानी से हो रहा है, और बुनियाद तैयार करने में समय लग रहा है। इस प्रक्रिया से Rust को जो अतिरिक्त लाभ मिल रहा है, वह बस एक bonus है

  • लेख में <i>field projection से जुड़ी बात में, अब यह तय किया गया है कि सभी struct fields को structural pinning मिलेगी, ताकि हमेशा Pin<&mut Field> जैसे types आएँ</i> यह पढ़ा, और महसूस हुआ कि मैं पहले इस हिस्से को मिस कर गया था। तकनीकी रूप से यह जटिल बात है, लेकिन अच्छा लगा कि इस निर्णय ने कई चर्चाओं को रोककर रखने वाली समस्या सुलझा दी

  • लोग <i>अंतिम design, जो C++ से प्रेरित है, उस अनुमानित optimization तकनीक</i> पर चर्चा कर रहे हैं जिसमें heap पर value allocate करने के लिए नया value बनाकर उसे तुरंत move करने की स्थिति में, उसे शुरुआत से ही heap पर create किया जाता है। यहाँ 'optimization' शब्द थोड़ा भ्रामक लग रहा है, इसलिए नाम बदलने पर भी चर्चा हो रही है

    • हो सकता है मैं समस्या की complexity पूरी तरह न समझ रहा हूँ, लेकिन क्या यह किसी उपयुक्त calling convention से आसानी से हल नहीं हो सकता? अगर struct का size x से बड़ा हो या उसमें marker type हो, तो caller outref के रूप में buffer दे और callee सीधे उसी buffer में struct लिख दे। ऐसा करने से सामान्य code लिखते हुए भी heap allocation की duplication रोकी जा सकती है, और दूसरी स्थितियों में भी अनावश्यक copying घट सकती है। इस विषय पर पहले से बहुत मेहनत लगी है, इसलिए उल्टा यह जानने की जिज्ञासा है कि प्रस्तावित समाधान ज़्यादा असुविधाजनक क्यों हैं

    • मुझे लगता है कि इसे internal optimization के रूप में संभालने के बजाय new जैसी किसी function से साफ़ तौर पर व्यक्त किया जाए तो सबके लिए ज़्यादा सहज होगा

    • C++ में इस तरह की semantic को elision कहा जाता है

    • 'coalesced heap construction' या 'coalesced heap allocation' जैसा नाम कैसा रहेगा, ऐसा सुझाव दिया गया

  • Rust के तरह-तरह के features की बात आते ही मैं मज़ाक में कहता हूँ, "बस Tokio को kernel में मत डालना।" अगर Rust काफ़ी आगे बढ़ जाए और direct composition renderer आ जाए, जिससे kernel के अंदर चलने वाले apps संभव हो जाएँ, तो वह भी काफ़ी दिलचस्प स्थिति होगी

    • Kernel के अंदर async runtime implement करना वास्तव में बहुत trivial है। सच तो यह है कि kernel की workqueue खुद ही एक runtime है

    • अगर यह मज़ाक नहीं है, तो आप kernel code को Rust (और C) में लिखने की संरचना को बुनियादी रूप से गलत समझ रहे हैं। Kernel में coding करते समय C stdlib की तरह Rust भी no_std में चलता है, और cargo या crates भी इस्तेमाल नहीं किए जा सकते। Tokio चलाना हो तो उसका आधा हिस्सा दोबारा लिखना पड़ेगा और sockets जैसी सारी OS interactions को kernel वाले तरीके से बदलना पड़ेगा

  • मेरा मानना है कि Linux में आने वाले Rust से जुड़े ये features सिर्फ़ kernel तक सीमित नहीं हैं, बल्कि Rust भाषा के लिए व्यापक रूप से उपयोगी शुरुआती features हैं। ऐसा भी लगा कि kernel-केंद्रित feature development ने दूसरी language/library feature development को कुछ हद तक रोके रखा था

    • मेरी जानकारी में systems programming, Rust का प्राथमिक application area है। OS, embedded, या जटिल C-based systems जैसी जगहों में interoperability सबसे अहम है। ये features असल में सिर्फ़ kernel-specific नहीं लगते, बल्कि वास्तविक systems programming के लिए ज़रूरी general utilities जैसे लगते हैं

    • Kernel/firmware development के लिए प्रगति कई जगहों पर हो रही है, लेकिन वह हमेशा सबकी दिलचस्पी का केंद्र नहीं बनती। Philipp खास तौर पर इस क्षेत्र में बड़े बदलाव ला रहे हैं

    • Rust की मुख्य भूमिका low-level systems programming है। इसके बाहर के क्षेत्रों में userspace compiled managed languages कहीं बेहतर विकल्प हैं, और Self, Inferno, या Android architecture जैसे ढाँचों वाले systems में इस तरह की low-level C-style capabilities पर ध्यान देना कोई समस्या नहीं है

  • ये features सिर्फ़ kernel ही नहीं, दूसरे क्षेत्रों में भी मददगार होने लायक़ शानदार features हैं (खासकर generalized projections)। यह बात बहुत संतोषजनक है कि Linux, Rust भाषा के विकास को आगे बढ़ा रहा है

  • सोच रहा हूँ कि क्या LLM का उपयोग करके C code को अपने-आप Rust में बदलने पर कोई research/tool है। क्या LLM से chat, USB, I2C, GPU driver जैसी Rust code लिखवाकर build/test तक कराया जा सकता है, या SQLite, Apache, Nginx जैसे 'थोड़े छोटे' projects पर भी इसे आज़माया जा सकता है

    • LLM-आधारित नहीं, बल्कि research के रूप में c2rust जैसा एक वास्तविक प्रोजेक्ट है। LLM मूल रूप से approximation तक सीमित रहते हैं, इसलिए वे सटीक काम नहीं कर पाते, और बहुत subtle bugs निकलते हैं। Formal methods जैसी चीज़ों को साथ न जोड़ा जाए तो यह व्यावहारिक नहीं है। सिर्फ़ unit tests से भी बहुत-सी समस्याएँ पकड़ में नहीं आतीं। और जिन उदाहरणों को 'छोटे' projects कहा गया है, वे भी असल में इतने छोटे नहीं हैं। वास्तविक उपयोग के उदाहरण देखें

    • Darpa ने भी इस तरह की research में रुचि लेकर funding दी है, लेकिन अभी तक नतीजे सामने आए हों, ऐसी स्थिति नहीं है
 
ahwjdekf 2025-10-17

कट्टरता में alignment