2012-01-29 12 views
5

ऑपरेटिंग सिस्टम में उपयोगकर्ता मोड एप्लिकेशन का वर्चुअल एड्रेस स्पेस निजी है, एक एप्लिकेशन दूसरे एप्लिकेशन से संबंधित डेटा को बदल नहीं सकता है। प्रत्येक एप्लिकेशन अलगाव में चलता है, और यदि कोई एप्लिकेशन क्रैश हो जाता है, तो क्रैश उस एप्लिकेशन तक सीमित है। अन्य अनुप्रयोगों और ऑपरेटिंग सिस्टम क्रैशकर्नेल मोड और मेमोरी सुरक्षा

क्यों नहीं कर्नेल मोड ओएस में स्मृति की रक्षा नहीं करता है और बीओएसडी होता है ??

+0

यह ऑफ-विषय क्यों बन गया ?? –

+0

यह मुझे ऑन-विषय osdev प्रश्न जैसा लगता है ... – bdonlan

उत्तर

8

सबसे पहले, कुछ स्तर पर आपके पास हमेशा एक घटक होगा जो विफल नहीं हो सकता है ™। यदि यह घटक दुर्घटनाग्रस्त हो जाता है, तो कोई वसूली संभव नहीं है। उदाहरण के लिए, यदि आप चल रही प्रक्रियाओं की तालिका को मिटाते हैं, तो आप इसे रीबूट करने के अलावा पुनर्निर्माण नहीं कर सकते हैं। तो स्मृति घटक के साथ भी इस घटक की दुर्घटनाओं को सीमित करने के लिए सीमित है, बीएसओडी (या समकक्ष) हो सकता है।

लेकिन आपका बिंदु एक अच्छा है - ऐसे कई घटक हैं जो अक्सर एक विनाशकारी विफलता के बिना रीसेट हो सकते हैं। ड्राइवर्स, उदाहरण के लिए, या नेटवर्किंग ढेर। दरअसल, ओएसई हैं जो इस स्तर पर सुरक्षा करते हैं - उन्हें microkernel architectures के रूप में जाना जाता है।

हालांकि माइक्रोक्रोनल्स के साथ समस्या प्रदर्शन है। X86 CPUs पर स्मृति सुरक्षा दो चीजों के साथ प्राप्त की जाती है - Current Privilege Level (सीपीएल, या 'ring'), 0 (अधिकतम पहुंच) और 3 (उपयोगकर्ता मोड), और Page Table के बीच की संख्या। पृष्ठ तालिका भौतिक पते पर आभासी पते को मानचित्र करती है, और प्रत्येक पृष्ठ पर पहुंच प्रतिबंध सेट करती है (स्मृति के 4096-बाइट ब्लॉक)। प्रत्येक प्रक्रिया की अपनी पृष्ठ तालिका होती है, और पृष्ठ तालिका में प्रत्येक पृष्ठ को अधिकतम सीपीएल, केवल-पढ़ने वाला ध्वज, कोई निष्पादित ध्वज, या कोई-एक्सेस ध्वज सेट करके प्रतिबंधित किया जा सकता है।

अपना सीपीएल बदलना अपेक्षाकृत तेज़ ऑपरेशन है (हालांकि इस पर सुरक्षा प्रतिबंध हैं कि आपको कब और कब ऐसा करने की अनुमति है)। पृष्ठ तालिका को बदलना, काफी महंगा है, क्योंकि इसे Translation Lookaside Buffer (TLB) नामक सीपीयू पर कैश साफ़ करने की आवश्यकता है।

आम तौर पर एक सामान्य ओएस में, ओएस उपयोगकर्ता प्रक्रियाओं के लिए सबसे कम एक्स जीबी मेमोरी आरक्षित करेगा (3 जीबी आमतौर पर 32-बिट आर्किटेक्चर के लिए चुना गया नंबर) होता है। ऊपरी (4 - एक्स) जीबी सीधे (4 - एक्स) जीबी की भौतिक मेमोरी में मैप की जाती है, और केवल सीपीएल 0 ('रिंग 0') तक ही सीमित होती है। इस प्रकार, कर्नेल अपने निजी डेटास्ट्रक्चर को ऊपरी 1 जीबी या उससे भी अधिक में रख सकता है और हमेशा उसी वर्चुअल एड्रेस पर उन्हें एक्सेस कर सकता है, इससे कोई फर्क नहीं पड़ता कि कौन सी प्रक्रिया चल रही है। यदि कोई प्रक्रिया एक सिस्कोल बनाती है जिसके लिए आधा दर्जन उपप्रणाली कुछ करने की आवश्यकता होती है, कोई समस्या नहीं - आप केवल उनके बीच कार्य को कॉल कर सकते हैं।

हालांकि, एक माइक्रोक्रोनर सिस्टम में, प्रत्येक कर्नेल उपप्रणाली को अपनी स्वयं की पृष्ठ तालिका और इसके स्वयं के पते मैपिंग मिलती है। उपयोगकर्ता कॉल की सेवा करने के लिए, सीपीयू को कुछ पेज टेबल परिवर्तन करने की आवश्यकता हो सकती है, और यह प्रदर्शन हिट जोड़ता है। इसके अलावा, प्रत्येक उपप्रणाली को इसकी निर्भरताओं की विफलताओं से निपटने के लिए तैयार किया जाना चाहिए, जिससे सिस्टम की जटिलता बढ़ जाती है। इन समस्याओं के कारण, माइक्रोकर्नल्स, बड़े पैमाने पर, केवल अनुसंधान और खिलौने ओएस के रूप में उपयोग किए जाते हैं (उदाहरण के लिए, minix, GNU HURD)।

ने कहा, हाल के वर्षों में, मैक्रो- और माइक्रो-कर्नेल के बीच की रेखा के कुछ धुंधले हुए हैं। उदाहरण के लिए, विंडोज 7 में, ग्राफिक्स ड्राइवर वास्तव में कर्नेल के बाकी हिस्सों से अलग है; अगर यह दुर्घटनाग्रस्त हो जाता है, तो सिस्टम ठीक हो सकता है। लिनक्स और ओएस एक्स में, FUSE उपयोगकर्ता स्पेस में फाइल सिस्टम ड्राइवर लोड कर सकते हैं; वास्तव में, इन तंत्रों पर एनटीएफएस चालक इस तंत्र का उपयोग करता है।

+0

धन्यवाद bdonlan.but मेरा सवाल सरल है। मैं जानना चाहता हूं "क्यों ऑपरेटिंग सिस्टम कर्नेल मोड में स्मृति (प्रत्येक घटक और केएमडी के लिए) अलग नहीं करता है ?? –

+0

@ एएस, मैंने समझाया। Microkernels वास्तव में स्मृति अलग है। वे इसके कारण धीमे हैं। – bdonlan

संबंधित मुद्दे