कुछ लोग किसी कारण से लिनक्स में उपयोगकर्ता स्थान से कर्नेल स्पेस में कोड ले जाना चाहते हैं। कई बार ऐसा लगता है कि कोड विशेष रूप से उच्च प्राथमिकता होनी चाहिए या बस "कर्नेल स्पेस तेज है"।मुझे लिनक्स कर्नेल मॉड्यूल कब लिखना चाहिए?
यह मेरे लिए अजीब लगता है। मुझे कर्नेल मॉड्यूल लिखने पर विचार कब करना चाहिए? क्या मानदंडों का एक सेट है?
मैं उपयोगकर्ता स्थान में कोड रखने को कैसे प्रेरित कर सकता हूं (मुझे विश्वास है) वहां से संबंधित है?
मुझे यकीन नहीं है कि सवाल सही तरीके से है। चीजों को कर्नेल स्पेस में स्थानांतरित करने का एक अच्छा कारण होना चाहिए। यदि कोई कारण नहीं है, तो ऐसा मत करो।
एक बात के लिए, डिबगिंग कठिन हो गई है, और बग का प्रभाव बहुत खराब है (सरल coredump के बजाय क्रैश/दहशत)।
कर्नेल में चल रहे कोड मेमोरी, परिधीय, सिस्टम फ़ंक्शंस को उन तरीकों से एक्सेस करते हैं जो उपयोगकर्ता स्पेस कोड से अलग हैं और इस प्रकार अधिक कुशल होने की क्षमता है। कर्नेल कोड के लिए कम सुरक्षा प्रतिबंधों का उल्लेख नहीं करना है। हालांकि, यह सब आमतौर पर लागत पर आता है, जैसे कि कर्नेल को सुरक्षा खतरों तक खोलने, ओएस को लॉक करने, डीबगिंग को जटिल करने, और आगे की संभावना को बढ़ाने की संभावना बढ़ रही है।
कर्नेल में सामान डालने के बहुत सीमित कारण हैं। यदि आप डिवाइस ड्राइवर लिख रहे हैं तो यह ठीक है। कोई मानक आवेदन: कभी नहीं।
दोष बहुत अधिक हैं। डिबगिंग कठिन हो जाती है, त्रुटियां अधिक बार-बार और कठिन होती हैं। आप सुरक्षा और स्थिरता समझौता कर सकते हैं। आपको कर्नेल परिवर्तनों को अधिक बार अनुकूलित करना पड़ सकता है। अन्य यूनिक्स ओएस को पोर्ट करना असंभव हो जाता है।
मैं सबसे करीब कर्नेल में आया हूं, एक कस्टम फाइल सिस्टम (पृष्ठभूमि में mysql के साथ) था और इसके लिए भी हमने FUSE (जहां यू यूजर स्पेस के लिए खड़ा था) का उपयोग किया था।
सामान्य नियम के रूप में। इस बारे में सोचें कि आप क्या जानना चाहते हैं और यदि ऐसा कुछ है जो आप एक ऑपरेटिंग सिस्टम डेवलपमेंट बुक या क्लास में देखेंगे तो उसके पास कर्नेल से संबंधित होने का अच्छा मौका होगा। यदि नहीं, तो इसे कर्नेल से बाहर रखें। यदि आपके पास उस नियम को तोड़ने का बहुत अच्छा कारण है, तो सुनिश्चित करें कि आपके पास यह जानने के लिए पर्याप्त ज्ञान होगा या आप उस व्यक्ति के साथ काम करेंगे जिसमें वह ज्ञान है।
हां, कठोर लग सकता है, लेकिन अगर आप नहीं जानते हैं, तो यह बिल्कुल सही है, तो लगभग सुनिश्चित करें कि उत्तर नहीं है, कर्नेल में ऐसा न करें। कर्नेल स्पेस में अपने विकास को स्थानांतरित करने से कीड़े का एक बड़ा हिस्सा खुलता है जिसे आपको संभालने में सक्षम होना चाहिए।
अंगूठे का नियम: उपयोगकर्ता कोड में अपना कोड रखने के लिए अपने पूर्ण सर्वोत्तम आज़माएं। यदि आपको नहीं लगता कि आप कर सकते हैं, तो कर्नेल कोड के विकल्प के रूप में अधिक समय व्यतीत करें क्योंकि आप कोड लिखेंगे (यानी: एक लंबा समय), और फिर उपयोगकर्ता-स्थान में इसे लागू करने के लिए फिर से प्रयास करें। यदि आप अभी भी नहीं कर सकते हैं, तो यह सुनिश्चित करने के लिए और अधिक शोध करें कि आप सही विकल्प बना रहे हैं, तो बहुत सावधानी से कर्नेल में स्थानांतरित करें। जैसा कि अन्य ने कहा है, बहुत कम परिस्थितियां हैं जो कर्नेल मॉड्यूल लिखने और कर्नेल कोड को डिबग करने का निर्देशन काफी नरक हो सकती हैं, इसलिए हर कीमत पर स्पष्ट हो जाएं।
जहां तक कंक्रीट स्थितियों को आपको कर्नेल-मोड कोड लिखने पर विचार करना चाहिए, यहां कुछ हैं: क्या इसे अत्यंत कम-स्तरीय संसाधनों जैसे कि इंटरप्ट्स तक पहुंच की आवश्यकता है?क्या आपका कोड हार्डवेयर के लिए एक नया इंटरफ़ेस/ड्राइवर परिभाषित कर रहा है जो वर्तमान में निर्यात की गई कार्यक्षमता के शीर्ष पर नहीं बनाया जा सकता है? क्या आपका कोड को डेटा संरचनाओं या प्राइमेटिव्स तक पहुंच की आवश्यकता है जिन्हें कर्नेल स्पेस से निर्यात नहीं किया गया है? क्या आप कुछ ऐसा लिख रहे हैं जिसका मुख्य रूप से अन्य कर्नेल उपप्रणाली जैसे शेड्यूलर या वीएम सिस्टम (यहां तक कि यह पूरी तरह से आवश्यक नहीं है कि सबसिस्टम कर्नेल-मोड हो: मैक के पास उपयोगकर्ता-मोड के लिए मजबूत समर्थन है वर्चुअल मेमोरी पेजर्स, तो यह निश्चित रूप से किया जा सकता है)?
यदि आपके लोग वास्तव में उच्च प्राथमिकता, निर्धारणा, कम विलंबता आदि चाहते हैं, तो जाने का सही तरीका लिनक्स (या अन्य ओएस) के कुछ वास्तविक समय संस्करण का उपयोग करना है।
भी पूर्ववत कर्नेल विकल्प इत्यादि देखें। सटीक रूप से आपको क्या करना चाहिए आवश्यकताओं पर निर्भर करता है, लेकिन कर्नेल मॉड्यूल में कोड डालने के लिए सही समाधान की संभावना नहीं है, जब तक कि आप कुछ हार्डवेयर को सीधे इंटरफेस नहीं कर लेते।
यदि आपको केवल कम विलंबता, उच्च थ्रूपुट इत्यादि की आवश्यकता है, तो शायद यह सस्ता कर्नेल कोड विकसित करने के बजाय एक तेज कंप्यूटर खरीदने के लिए है।
कर्नेल मॉड्यूल (कम संदर्भ स्विच, कम सिस्टम कॉल भूमि के ऊपर, और कम रुकावट के कारण) तेजी से हो सकता है, और निश्चित रूप से बहुत उच्च प्राथमिकता पर रन से करते हैं। यदि आप कर्नेल स्पेस में काफी सरल कोड का निर्यात करना चाहते हैं, तो यह ठीक हो सकता है। यही है, यदि प्रदर्शन के लिए कोड का एक छोटा टुकड़ा महत्वपूर्ण पाया जाता है, और कर्नेल मोड में रखा जाने वाला लाभ कोड है, तो इसे वहां रखने के लिए उचित हो सकता है।
लेकिन आपके प्रोग्राम के बड़े हिस्सों को कर्नेल स्पेस में ले जाने से बचा जाना चाहिए जब तक कि अन्य सभी विकल्प पूरी तरह समाप्त न हों। ऐसा करने में कठिनाई के अलावा, प्रदर्शन लाभ बहुत बड़ा होने की संभावना नहीं है।
लागत कोई फर्क नहीं पड़ता कि तेज कंप्यूटर मौजूद नहीं हैं। लेकिन उन मामलों के लिए, एक रीयलटाइम ओएस पर जाने से शायद कर्नेल को घटाने से बेहतर होता है। – Tom
असल में, मैं आरपीजे से सहमत हूं। कोड उपयोगकर्ता-स्थान में होना चाहिए, जब तक कि यह वास्तव में आवश्यक न हो।
लेकिन, आपके प्रश्न पर जोर देने के लिए, किस स्थिति में?
कुछ लोग दावा करते हैं कि ड्राइवर को कर्नेल में होना चाहिए, जो सत्य नहीं है। कुछ ड्राइवर समय-समय पर संवेदनशील नहीं होते हैं, वास्तव में बहुत सारे ड्राइवर इस तरह होते हैं।
उदाहरण के लिए, फ़्रेमर, आरटीसी टाइमर, i2c डिवाइस, आदि। उन ड्राइवरों को आसानी से उपयोगकर्ता स्थान पर ले जाया जा सकता है। यहां तक कि कुछ फ़ाइल-सिस्टम भी हैं जो उपयोगकर्ता-स्थान में लिखे गए हैं।
आपको कर्नेल स्पेस पर जाना चाहिए जहां ओवरहेड, उदाहरण के लिए। उपयोगकर्ता-कर्नेल स्वैप, आपके कोड के लिए ठीक से काम करने के लिए अस्वीकार्य हो जाता है।
लेकिन इससे निपटने के लिए बहुत सारे तरीके हैं। उदाहरण के लिए,/dev/mem आपकी भौतिक स्मृति तक पहुंचने का एक अच्छा तरीका प्रदान करता है, जैसे आप इसे कर्नेल स्पेस से करते हैं।
जब लोग आरटीओएस जाने के बारे में बात करते हैं, तो मैं आमतौर पर संदेह करता हूं। इन दिनों, प्रोसेसर इतना शक्तिशाली है, कि ज्यादातर समय, वास्तविक समय पहलू नगण्य हो जाता है।
लेकिन यहां तक कि, मान लें कि आप सोनेट से बात कर रहे हैं, और आपको 50ms के भीतर सुरक्षा स्विचिंग करने की आवश्यकता है (वास्तव में भी कम, क्योंकि 50 मिमी बाधा पूरी अंगूठी पर लागू होती है), आप अभी भी स्विचिंग कर सकते हैं तेज़, अगर आपका हार्डवेयर इसका समर्थन करता है।
इन दिनों बहुत सारे फ़्रेमर आपको हार्डवेयर समर्थन दे सकते हैं जो आपको लिखने की आवश्यकता को कम कर देता है। आपका काम मूल रूप से जितनी जल्दी हो सके बाधा का जवाब देता है। और लिनक्स बिल्कुल बुरा नहीं है। मुझे मिली इंटरप्ट विलंबता कम 1ms थी, भले ही मेरे पास कई अन्य इंटरप्ट चल रहे हों (उदाहरण के लिए आईडीई, ईथरनेट इत्यादि)।
और यदि यह अभी भी पर्याप्त नहीं है, तो हो सकता है कि आपका हार्डवेयर डिज़ाइन गलत हो। हार्डवेयर पर कुछ चीजें बेहतर रहती हैं। और जब मैंने हार्डवेयर कहा, मेरा मतलब एएसआईसी, एफपीजीए, नेटवर्क प्रोसेसर, या अन्य उन्नत तर्क है।
यदि आप ऐसा प्रश्न पूछ रहे हैं, तो आपको कर्नेल परत पर नहीं जाना चाहिए। असल में बस सोचने का मतलब है कि आपको इसकी आवश्यकता नहीं है। संदर्भ स्विच का समय इतना नगण्य है कि इससे इन दिनों वैसे भी कोई फर्क नहीं पड़ता।
कर्नेल स्पेस में कोड नहीं ले जाने का एक अन्य कारण यह है कि जब आप इसे उत्पादन या वाणिज्यिक परिस्थितियों में उपयोग करते हैं, तो आपको जीपीएल समझौते के कारण उस कोड को प्रकाशित करना होगा। ऐसी स्थिति है कि कई सॉफ्टवेयर कंपनियां नहीं आना चाहती हैं। :)
सुरक्षा मुद्दों का उल्लेख नहीं करना है (क्या आपका कोड 100% हैकिंग सबूत है? मामूली बग एक विशाल बैक-दरवाजा बन सकता है!), संपार्श्विक क्षति के मुद्दों (एक सूक्ष्म बग आपके ऐप से कहीं अधिक प्रभावित हो सकता है) इत्यादि। –