लिनक्स कर्नेल Rust 1.77 अपग्रेड की तैयारी कर रहा है

मूल लेख ↗ Hacker News चर्चा ↗

लिनक्स द्वारा नए Rust toolchains, जिसमें Rust 1.77 का नियोजित अपग्रेड शामिल है, की ओर बढ़ना इस बहस को तेज कर रहा है कि कर्नेल को अस्थिर compiler features पर कितना निर्भर होना चाहिए और इसका दीर्घकालिक maintainability पर क्या असर होगा। टिप्पणीकार Rust के लाभों—memory safety, modern abstractions, और विकसित होती allocator support—को व्यावहारिक चिंताओं जैसे compiler bootstrapping, binary size, और कर्नेल code में Rust के अभी भी बहुत छोटे हिस्से के सामने तौलते हैं। व्यापक सहमति यह है कि फिलहाल Rust कर्नेल में optional और incremental ही रहेगा, और low-level systems work के लिए भाषा और उसके tooling को आकार देने का एक testbed बना रहेगा।

Rust वर्ज़निंग और कर्नेल द्वारा अस्थिर फीचर्स का उपयोग

  • स्थिर Rust का उपयोग करने वाली सामान्य परियोजनाओं में, कंपाइलर अपग्रेड अधिकांशतः backward compatible होते हैं; clippy और cargo fmt जैसे टूल स्टाइल और lint परिवर्तनों को ट्रैक करने में मदद करते हैं।
  • Rust-for-Linux जानबूझकर nightly/unstable फीचर्स का उपयोग करता है, इसलिए अपग्रेड के लिए गैर-तुच्छ fixes की आवश्यकता हो सकती है।
  • इसे उन गायब फीचर्स (जैसे offset_of, allocator APIs) का उपयोग करने और उन्हें stabilization की ओर धकेलने में मदद करने के लिए आवश्यक माना जाता है।
  • उद्धृत अनुमान: बड़े codebases में कंपाइलर अपग्रेड के लिए प्रति million lines of Rust लगभग ~0.5 घंटे; nightly उपयोग के कारण Rust-for-Linux का overhead अधिक है।

Allocators और memory handling

  • कर्नेल को fine-grained, fallible, और per-object-type allocation की आवश्यकता है, जिससे वह केवल GlobalAlloc के बजाय unstable Allocator APIs की ओर बढ़ता है।
  • allocator_api fallible construction (जैसे try_new) और ऐसी flexibility प्रदान करता है जो stable APIs में नहीं होती।
  • केवल standard library को unstable features उपयोग करने की अनुमति है; third-party crates stable पर ऐसा नहीं कर सकते।

Binary size और dependencies

  • Rust की binary-size संबंधी कई शिकायतें इनसे जुड़ी हैं:
    • Debug/panic machinery (जैसे backtrace, Unicode-aware formatting)।
    • std का static linking।
    • भारी dependency trees और monomorphization।
  • no-std contexts (microcontrollers, kernel) में binaries बहुत छोटे हो सकते हैं।
  • Strip/debug-splitting और आने वाले Cargo defaults sizes को कम करेंगे; लेकिन Rust का “hello world” अभी भी C की तुलना में अपेक्षाकृत बड़ा constant overhead रखता है।
  • कुछ लोगों का कहना है कि बड़े build trees और caches (सैकड़ों MB) समस्याजनक हैं; अन्य लोग नोट करते हैं कि यह modern toolchains के समान है और in-kernel Rust बड़े dependency graphs नहीं खींचेगा।

कर्नेल में Rust की मात्रा और संरचना

  • वर्तमान में Rust code कर्नेल का बहुत छोटा हिस्सा है (लगभग ~0.03–0.05% lines के order में)।
  • अधिकांश हिस्सा infrastructure है; Rust drivers अभी भी “rounding errors” हैं, जैसे Android binder rewrite के उदाहरण।
  • कर्नेल core और custom alloc का उपयोग करता है, लेकिन std का नहीं।

Bootstrapping, LFS, और toolchains

  • चिंता: Rust की bootstrapping कहानी “ugly” है और Linux From Scratch (LFS) के लिए खतरा हो सकती है।
  • प्रतिवाद: LFS पहले से ही host C compiler मानता है; उसी तरह वह host Rust compiler मान सकता है और केवल object files बनाने के लिए rustc का उपयोग कर सकता है।
  • अन्य जटिल compilers (जैसे GHC) को bootstrapping करने की तुलना में, Rust की स्थिति की आलोचना की जाती है लेकिन वह अनोखी नहीं है।

Low-level safety, pointers, और language choice

  • unsafe pointer operations और macros बनाम safe pointer arithmetic पर चर्चा subtle UB और performance trade-offs को उजागर करती है।
  • Rust की library layers की स्पष्टता: core (language primitives), alloc (heap types), std (OS-dependent features)।
  • कुछ लोग केवल language rewrite नहीं, बल्कि seL4 जैसी formal verification चाहते हैं।
  • यह प्रश्न उठाया गया: “Rust की जगह Zig क्यों?”
    • एक पक्ष Rust की मजबूत memory-safety guarantees को महत्व देता है।
    • दूसरा पक्ष कहता है कि memory bugs को tests से संभाला जा सकता है और Rust की safety के अपने trade-offs हैं; कोई consensus नहीं बन पाया।