कुछ हफ्ते पहले के बारे में समाचार जारी किया गया था कुछ कार्यान्वयन जो किए गए थे लिनक्स-अगली शाखा, जिसमें घटकों का प्रारंभिक सेट शामिल है डिवाइस ड्राइवर विकसित करना रस्ट भाषा में.
इस तरह के दस्तावेज़ को लिनक्स कर्नेल में रस्ट के उपयोग और रस्ट भाषा में एक कैरेक्टर डिवाइस ड्राइवर के साथ कर्नेल मॉड्यूल के उदाहरण पर अलग से प्रकाशित किया गया था। कोड शाखा के अनुरक्षक स्टीफन रोथवेल द्वारा जोड़ा गया था।
उसके बाद लिनस टोरवाल्ड्स ने कार्यान्वयन की समीक्षा की लिनक्स कर्नेल में जंग भाषा ड्राइवरों को सेट करने के लिए संभावनाओं का पैच और कुछ आलोचना की।
के कारण सबसे बड़ी शिकायतें थीं भागने की क्षमता गलत परिस्थितियों में "रन-टाइम असफलता घबराहट", उदाहरण के लिए, एक आउट-ऑफ-मेमोरी स्थिति में, जब कर्नेल संचालन सहित गतिशील मेमोरी आवंटन संचालन विफल हो सकता है।
टोर्वाल्ड कहा कि कर्नेल पर इस तरह का ध्यान मौलिक रूप से अस्वीकार्य है, और यदि आप इस बिंदु को नहीं समझते हैं, तो आप किसी भी कोड को पूरी तरह से अस्वीकार कर सकते हैं जो इस तरह के दृष्टिकोण का उपयोग करने की कोशिश करता है। दूसरी ओर, पैच के डेवलपर समस्या से सहमत थे और इसे हल करने योग्य मानते थे।
एक अन्य समस्या फ़्लोटिंग पॉइंट या 128-बिट प्रकारों का उपयोग करने का प्रयास है, जो लिनक्स कर्नेल जैसे वातावरण के लिए मान्य नहीं हैं।
हो सकता है आप यह न समझें कि ऐसा कब हो सकता है, इसलिए हो सकता है
जितना मैं समझता हूं यह उतना बड़ा मुद्दा नहीं है, लेकिन बुनियादी तौर पर
मुझे लगता है कि अगर कोई रस्ट मैपिंग घबराहट पैदा कर सकती है तो बस यही है
_मौलिक रूप से_ स्वीकार्य नहीं है.नियंत्रक या गैर-कोर कोड में असाइनमेंट विफलता, और वह है, के लिए
परिभाषा, सभी नए जंग कोड, कभी भी इसका कारण नहीं बन सकते
वैध रूप से घबराओ. वही बात लागू होती है "ओह, कुछ मामलों में मैंने इसके उपयोग का परीक्षण नहीं किया
128-बिट या फ़्लोटिंग-पॉइंट पूर्णांक।इसलिए यदि रस्ट कंपाइलर छिपे हुए आवंटन का कारण बनता है तो ऐसा नहीं हो सकता है
पता लगाएं और त्रुटियों के रूप में वापस लौटें, तो मैं गंभीरता से विश्वास करता हूं कि यह सब
दृष्टिकोण पूरी तरह से NAK'ed होना चाहिए, और रस्ट इंफ्रास्ट्रक्चर,
या तो कंपाइलर स्तर पर या कर्नेल रैपर्स में, आपको और अधिक की आवश्यकता है
नौकरी.
यह और भी गंभीर समस्या साबित हुई, इस समय से रस्ट की केंद्रीय लाइब्रेरी अविभाज्य है और एक बड़ी बूँद का प्रतिनिधित्व करती है; केवल कुछ सुविधाओं के लिए अनुरोध करने का कोई तरीका नहीं है, जो एक या अन्य समस्याग्रस्त कार्यक्षमता के उपयोग को रोकता है।
समस्या के समाधान के लिए रस्ट कंपाइलर और लाइब्रेरी में बदलाव की आवश्यकता हो सकती है, हालांकि टीम के पास अभी तक भाषा लाइब्रेरी की मॉड्यूलरिटी को लागू करने की कोई रणनीति नहीं है।
इसके अलावा, टोरवाल्ड्स ने बताया कि प्रदान किया गया उदाहरण नियंत्रक बेकार है और एक उदाहरण के रूप में कुछ ड्राइवर संलग्न करने की सलाह दी जो वास्तविक समस्याओं में से एक को हल करता है।
इससे पहले Google ने Linux कर्नेल में रस्ट समर्थन को बढ़ावा देने की एक पहल में अपनी भागीदारी की घोषणा की। y तकनीकी पहलू उपलब्ध कराए स्मृति के साथ काम करने में त्रुटियों से उत्पन्न होने वाली समस्याओं से निपटने के लिए रस्ट को लागू करने की व्यवहार्यता के बारे में।
Google को लगता है कि रस्ट एक विकास भाषा के रूप में C में शामिल होने के लिए तैयार है लिनक्स कर्नेल घटक. लेख एंड्रॉइड प्लेटफ़ॉर्म पर इसके उपयोग के संदर्भ में, कर्नेल ड्राइवरों को विकसित करने के लिए रस्ट भाषा का उपयोग करने के उदाहरण भी प्रदान करता है (रस्ट को एंड्रॉइड विकास के लिए आधिकारिक तौर पर समर्थित भाषा के रूप में मान्यता प्राप्त है)।
यह ध्यान दिया जाना चाहिए कि Google ने रस्ट में लिखे ड्राइवर का प्रारंभिक प्रोटोटाइप तैयार किया है बाइंडर के अंतर-प्रक्रिया संचार तंत्र के लिए, जो बाइंडर के सी और रस्ट कार्यान्वयन के प्रदर्शन और सुरक्षा की विस्तृत तुलना की अनुमति देगा।
अपने वर्तमान स्वरूप में, काम अभी तक पूरा नहीं हुआ है, लेकिन बाइंडर के काम करने के लिए आवश्यक कर्नेल कार्यक्षमता के लगभग सभी बुनियादी अमूर्तताओं के लिए, रस्ट कोड में इन अमूर्तताओं का उपयोग करने के लिए परतें तैयार की गई हैं।
अंत में, यदि आप इसके बारे में अधिक जानना चाहते हैं, तो आप विवरण देख सकते हैं निम्नलिखित लिंक में
आपकी सभी आलोचनाएँ मान्य हैं, यह देखते हुए कि रस्ट एक नई भाषा है जो सी से भिन्न प्रतिमान के साथ काम करती है, पुस्तकालयों में या कंपाइलर में किसी भी विवरण के बारे में चिंतित होना समझ में आता है, जहां कोड मान्य होने के बावजूद, यह टूट जाता है कर्नेल जैसा है वैसा ही है। इसे कैसे कार्यान्वित और निर्मित किया जाता है। यही कारण है कि लाइब्रेरी को मॉड्यूलर करने में सक्षम होने और केवल उन कार्यों को सक्रिय रखने में सक्षम होने जैसे प्रोग्राम (या इस मामले में किसी भी नियंत्रक के लिए) सही ढंग से काम करने के लिए आवश्यक हैं। यह भी अनुचित नहीं है, कि वे आपके लिए एक वास्तविक प्रोटोटाइप ड्राइवर लाते हैं जो मौजूदा समस्या पर अच्छा काम करता है (या कम से कम कर्नेल में मौजूदा ड्राइवर के समान ही काम करता है और बिना घबराए काम करता है)।
समय-समय पर मैं इनके लेख दोबारा पढ़ता हूं Linux Adictos लेकिन मुझे निराश होने में बहुत कम समय लगता है जब मैं देखता हूं कि बहुत अच्छी सामग्री होने के बावजूद, अंतिम परिणाम भयानक वर्तनी के साथ नष्ट हो जाता है।
क्या वर्तनी और व्याकरण इतना कठिन होगा?
शर्म की बात!
खुश हो जाओ!