माइक्रोकर्नेल: Difference between revisions

From Vigyanwiki
No edit summary
 
(One intermediate revision by one other user not shown)
Line 167: Line 167:
<ref>{{cite web |title=तुल्यकालिक संदेश पासिंग|url=http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.sys_arch/topic/ipc_Sync_messaging.html |access-date=14 July 2019 |ref=qnx_ipc}}</ref>
<ref>{{cite web |title=तुल्यकालिक संदेश पासिंग|url=http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.sys_arch/topic/ipc_Sync_messaging.html |access-date=14 July 2019 |ref=qnx_ipc}}</ref>


[[Category:All articles containing potentially dated statements]]
 
[[Category:All articles with unsourced statements]]
 
[[Category:Articles containing potentially dated statements from 2012]]
 
[[Category:Articles with invalid date parameter in template]]
 
[[Category:Articles with short description]]
 
[[Category:Articles with unsourced statements from August 2010]]
 
[[Category:Articles with unsourced statements from June 2015]]
 
[[Category:Articles with unsourced statements from November 2012]]
 
[[Category:CS1 errors]]
 


== सर्वर ==
== सर्वर ==
Line 184: Line 184:
इसके अतिरिक्त, कई क्रैश केवल [[क्रैश-ओनली सॉफ्टवेयर]] द्वारा ठीक किए जा सकते हैं। हालांकि, विफल सर्वर के साथ सिस्टम स्थिति का हिस्सा खो गया है, इसलिए इस दृष्टिकोण को विफलता से निपटने के लिए अनुप्रयोगों की आवश्यकता होती है। एक अच्छा उदाहरण इंटरनेट प्रोटोकॉल सूट के लिए जिम्मेदार एक सर्वर है। टीसीपी/आईपी कनेक्शन: यदि यह सर्वर फिर से शुरू होता है, तो एप्लिकेशन एक खोए हुए कनेक्शन का अनुभव करेंगे, जो नेटवर्क सिस्टम में एक सामान्य घटना है। अन्य सेवाओं के लिए, विफलता की उम्मीद कम है और इसके लिए एप्लिकेशन कोड में बदलाव की आवश्यकता हो सकती है। क्यूएनएक्स के लिए, क्यूएनएक्स उच्च उपलब्धता टूलकिट के रूप में पुनः आरंभ करने की क्षमता प्रदान की जाती है।<ref>{{cite web|url=http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|title=क्यूएनएक्स उच्च उपलब्धता टूलकिट|archive-url=https://web.archive.org/web/20050824015422/http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|archive-date=24 August 2005 }}</ref>
इसके अतिरिक्त, कई क्रैश केवल [[क्रैश-ओनली सॉफ्टवेयर]] द्वारा ठीक किए जा सकते हैं। हालांकि, विफल सर्वर के साथ सिस्टम स्थिति का हिस्सा खो गया है, इसलिए इस दृष्टिकोण को विफलता से निपटने के लिए अनुप्रयोगों की आवश्यकता होती है। एक अच्छा उदाहरण इंटरनेट प्रोटोकॉल सूट के लिए जिम्मेदार एक सर्वर है। टीसीपी/आईपी कनेक्शन: यदि यह सर्वर फिर से शुरू होता है, तो एप्लिकेशन एक खोए हुए कनेक्शन का अनुभव करेंगे, जो नेटवर्क सिस्टम में एक सामान्य घटना है। अन्य सेवाओं के लिए, विफलता की उम्मीद कम है और इसके लिए एप्लिकेशन कोड में बदलाव की आवश्यकता हो सकती है। क्यूएनएक्स के लिए, क्यूएनएक्स उच्च उपलब्धता टूलकिट के रूप में पुनः आरंभ करने की क्षमता प्रदान की जाती है।<ref>{{cite web|url=http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|title=क्यूएनएक्स उच्च उपलब्धता टूलकिट|archive-url=https://web.archive.org/web/20050824015422/http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|archive-date=24 August 2005 }}</ref>


[[Category:All articles containing potentially dated statements]]
 
[[Category:All articles with unsourced statements]]
 
[[Category:Articles containing potentially dated statements from 2012]]
 
[[Category:Articles with invalid date parameter in template]]
 
[[Category:Articles with short description]]
 
[[Category:Articles with unsourced statements from August 2010]]
 
[[Category:Articles with unsourced statements from June 2015]]
 
[[Category:Articles with unsourced statements from November 2012]]
 
[[Category:CS1 errors]]
 


== डिवाइस ड्राइवर ==
== डिवाइस ड्राइवर ==
Line 269: Line 269:
इस बीच यह दिखाया गया है कि उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर गीगाबिट ईथरनेट जैसे उच्च-थ्रूपुट, उच्च-इंटरप्ट डिवाइस के लिए भी इन-कर्नेल ड्राइवरों के प्रदर्शन के करीब आ सकते हैं।<ref name="Leslie_CFGGMPSEH_05">{{cite journal |last1=Leslie |first1=Ben |last2=Chubb|first2= Peter|last3 = FitzRoy-Dale|first3= Nicholas|last4= Götz|first4 =Stefan|last5= Gray|first5= Charles|last6= Macpherson|first6= Luke|last7= Potts|first7= Daniel|last8= Shen|first8= Yueting|last9= Elphinstone|first9= Kevin| author-link10=Gernot Heiser|last10=Heiser|first10= Gernot | date=September 2005 |title=उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर: प्रदर्शन हासिल किया|journal=Journal of Computer Science and Technology |volume=20 |issue=5 |pages=654–664 |doi=10.1007/s11390-005-0654-4|s2cid=1121537 }}</ref> ऐसा प्रतीत होता है कि उच्च-प्रदर्शन बहु-सर्वर सिस्टम संभव हैं।
इस बीच यह दिखाया गया है कि उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर गीगाबिट ईथरनेट जैसे उच्च-थ्रूपुट, उच्च-इंटरप्ट डिवाइस के लिए भी इन-कर्नेल ड्राइवरों के प्रदर्शन के करीब आ सकते हैं।<ref name="Leslie_CFGGMPSEH_05">{{cite journal |last1=Leslie |first1=Ben |last2=Chubb|first2= Peter|last3 = FitzRoy-Dale|first3= Nicholas|last4= Götz|first4 =Stefan|last5= Gray|first5= Charles|last6= Macpherson|first6= Luke|last7= Potts|first7= Daniel|last8= Shen|first8= Yueting|last9= Elphinstone|first9= Kevin| author-link10=Gernot Heiser|last10=Heiser|first10= Gernot | date=September 2005 |title=उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर: प्रदर्शन हासिल किया|journal=Journal of Computer Science and Technology |volume=20 |issue=5 |pages=654–664 |doi=10.1007/s11390-005-0654-4|s2cid=1121537 }}</ref> ऐसा प्रतीत होता है कि उच्च-प्रदर्शन बहु-सर्वर सिस्टम संभव हैं।


[[Category:All articles containing potentially dated statements]]
 
[[Category:All articles with unsourced statements]]
 
[[Category:Articles containing potentially dated statements from 2012]]
 
[[Category:Articles with invalid date parameter in template]]
 
[[Category:Articles with short description]]
 
[[Category:Articles with unsourced statements from August 2010]]
 
[[Category:Articles with unsourced statements from June 2015]]
 
[[Category:Articles with unsourced statements from November 2012]]
 
[[Category:CS1 errors]]
 


== सुरक्षा ==
== सुरक्षा ==
Line 367: Line 367:
SEL4 के मामले में, कार्यान्वयन का पूर्ण औपचारिक सत्यापन हासिल कर लिया गया है, [34] यानी एक गणितीय प्रमाण है कि कर्नेल का कार्यान्वयन इसके औपचारिक विनिर्देश के अनुरूप है। यह एक गारंटी प्रदान करता है कि एपीआई के बारे में साबित गुण वास्तव में वास्तविक कर्नेल के लिए धारण करते हैं, आश्वासन की एक डिग्री जो सीसी ईएएल7 से भी आगे जाती है। इसके बाद एपीआई के सुरक्षा-प्रवर्तन गुणों के प्रमाण दिए गए, और एक प्रमाण यह प्रदर्शित करता है कि निष्पादन योग्य बाइनरी कोड सी कार्यान्वयन का सही अनुवाद है, जो टीसीबी से संकलक को बाहर ले जाता है। एक साथ लेने पर, ये प्रमाण कर्नेल के सुरक्षा गुणों का एक सिरे से अंत तक का प्रमाण स्थापित करते हैं। [39]
SEL4 के मामले में, कार्यान्वयन का पूर्ण औपचारिक सत्यापन हासिल कर लिया गया है, [34] यानी एक गणितीय प्रमाण है कि कर्नेल का कार्यान्वयन इसके औपचारिक विनिर्देश के अनुरूप है। यह एक गारंटी प्रदान करता है कि एपीआई के बारे में साबित गुण वास्तव में वास्तविक कर्नेल के लिए धारण करते हैं, आश्वासन की एक डिग्री जो सीसी ईएएल7 से भी आगे जाती है। इसके बाद एपीआई के सुरक्षा-प्रवर्तन गुणों के प्रमाण दिए गए, और एक प्रमाण यह प्रदर्शित करता है कि निष्पादन योग्य बाइनरी कोड सी कार्यान्वयन का सही अनुवाद है, जो टीसीबी से संकलक को बाहर ले जाता है। एक साथ लेने पर, ये प्रमाण कर्नेल के सुरक्षा गुणों का एक सिरे से अंत तक का प्रमाण स्थापित करते हैं। [39]


[[Category:All articles containing potentially dated statements]]
 
[[Category:All articles with unsourced statements]]
 
[[Category:Articles containing potentially dated statements from 2012]]
 
[[Category:Articles with invalid date parameter in template]]
 
[[Category:Articles with short description]]
 
[[Category:Articles with unsourced statements from August 2010]]
 
[[Category:Articles with unsourced statements from June 2015]]
 
[[Category:Articles with unsourced statements from November 2012]]
 
[[Category:CS1 errors]]
 


== उदाहरण [edit] ==
== उदाहरण [edit] ==
Line 434: Line 434:
[[फाई:कायट्टोर्जेस्टेलमैन यदिन#मिक्रोयडिन]]
[[फाई:कायट्टोर्जेस्टेलमैन यदिन#मिक्रोयडिन]]


[[Category: Machine Translated Page]]
[[Category:All articles containing potentially dated statements]]
[[Category:All articles with unsourced statements]]
[[Category:Articles containing potentially dated statements from 2012]]
[[Category:Articles with invalid date parameter in template]]
[[Category:Articles with short description]]
[[Category:Articles with unsourced statements from August 2010]]
[[Category:Articles with unsourced statements from June 2015]]
[[Category:Articles with unsourced statements from November 2012]]
[[Category:CS1 errors]]
[[Category:CS1 français-language sources (fr)]]
[[Category:CS1 maint]]
[[Category:CS1 Ελληνικά-language sources (el)]]
[[Category:Citation Style 1 templates|W]]
[[Category:Collapse templates]]
[[Category:Created On 23/11/2022]]
[[Category:Created On 23/11/2022]]
[[Category:Vigyan Ready]]
[[Category:Machine Translated Page]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists]]
[[Category:Pages with reference errors]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Sidebars with styles needing conversion]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates based on the Citation/CS1 Lua module]]
[[Category:Templates generating COinS|Cite web]]
[[Category:Templates generating microformats]]
[[Category:Templates that are not mobile friendly]]
[[Category:Templates used by AutoWikiBrowser|Cite web]]
[[Category:Templates using TemplateData]]
[[Category:Use dmy dates from February 2021]]
[[Category:Wikipedia fully protected templates|Cite web]]
[[Category:Wikipedia metatemplates]]

Latest revision as of 10:14, 13 December 2022

क्रमशः मोनोलिथिक और माइक्रोकर्नेल-आधारित ऑपरेटिंग सिस्टम की संरचना

कंप्यूटर विज्ञान में, एक माइक्रोकर्नेल (प्रायः संक्षिप्त रूप में इसे μ-कर्नेल के नाम  से जाना जाता है ) सॉफ़्टवेयर की लगभग-न्यूनतम मात्रा है जो एक ऑपरेटिंग सिस्टम (OS) को लागू करने के लिए आवश्यक यांत्रिकी प्रदान कर सकता है। इस यांत्रिकी में निम्न-स्तरीय पता स्थान प्रबंधन, थ्रेड (कंप्यूटिंग) प्रबंधन और अंतर-प्रक्रिया संचार (IPC) सम्मलित हैं।

यदि हार्डवेयर एकाधिक रिंग या CPU मोड प्रदान करता है, तो माइक्रोकर्नेल एकमात्र सॉफ्टवेयर हो सकता है जो सबसे विशेषाधिकार प्राप्त स्तर पर निष्पादित होता है, जिसे सामान्यतः कर्नेल मोड कहा जाता है। पारंपरिक ऑपरेटिंग सिस्टम कार्यो, जैसे डिवाइस ड्राइवर, प्रोटोकॉल स्टैक और फाइल सिस्टम, सामान्यतः माइक्रोकर्नेल से ही हटा दिए जाते हैं और इसके अतिरिक्त उपयोक्ता स्थान में चलाए जाते हैं।[1] स्रोत कोड आकार के संदर्भ में, माइक्रोकर्नेल प्रायः अखंड कर्नेल से छोटे होते हैं। उदाहरण के लिए, MINIX 3 माइक्रोकर्नेल में, कोड की लगभग 12,000 पंक्तियाँ होती हैं।[2]


इतिहास

माइक्रोकर्नेल अपनी जड़ों को डेनिश कंप्यूटर अग्रणी प्रति ब्रिन्च हैनसेन और डेनिश कंप्यूटर कंपनी कंप्यूटिंग केंद्र में अपने कार्यकाल के लिए खोजते हैं जहाँ उन्होंने RC 4000 कंप्यूटर के लिए सॉफ्टवेयर विकास प्रयासों का नेतृत्व किया।[3] 1967 में, रेग्नेसेन्ट्रलेन पोलैंड में ज़कलाडी अज़ोतोवे पुलावी उर्वरक संयंत्र में एक RC 4000 प्रोटोटाइप स्थापित कर रहा था। कंप्यूटर ने संयंत्र की जरूरतों के अनुरूप एक छोटे रीयल-टाइम ऑपरेटिंग सिस्टम का उपयोग किया। ब्रिन्च हैनसेन और उनकी टीम RC 4000 प्रणाली की सामान्यता और पुन: प्रयोज्यता की कमी से चिंतित हो गई। उन्हें डर था कि प्रत्येक स्थापना के लिए एक अलग ऑपरेटिंग सिस्टम की आवश्यकता होगी, इसलिए उन्होंने RC 4000 के लिए सॉफ्टवेयर बनाने के नए और अधिक सामान्य तरीकों की जांच शुरू कर दी।[4] 1969 में, उनके प्रयास के परिणामस्वरूप आरसी 4000 मल्टीप्रोग्रामिंग सिस्टम पूरा हुआ। इसके नाभिक ने 23 अप्रतिबंधित प्रक्रियाओं के लिए संदेश-पासिंग के आधार पर अंतर-प्रक्रिया संचार प्रदान किया, जिनमें से 8 एक समय में एक दूसरे से सुरक्षित थे। इसने अन्य चल रहे कार्यक्रमों के अनुरोध पर कार्यक्रम के निष्पादन के समानांतर, दीक्षा और नियंत्रण में निष्पादित कार्यक्रमों के समय-समय पर शेड्यूलिंग को लागू किया, और बाह्य उपकरणों से डेटा स्थानांतरण की शुरुआत की। इन प्राथमिक तंत्रों के अलावा, इसमें कार्यक्रम निष्पादन और संसाधन आवंटन के लिए कोई अंतर्निहित रणनीति नहीं थी। इस रणनीति को चल रहे कार्यक्रमों के एक पदानुक्रम द्वारा कार्यान्वित किया जाना था जिसमें मूल प्रक्रियाओं का बाल प्रक्रियाओं पर पूर्ण नियंत्रण था और उनके ऑपरेटिंग सिस्टम के रूप में कार्य करता था।[5][6] ब्रिंच हैनसेन के काम के बाद, 1970 के दशक से माइक्रोकर्नेल विकसित किए गए हैं।[7] माइक्रोकर्नेल शब्द पहली बार 1981 के बाद दिखाई दिया।[8] माइक्रोकर्नेल कंप्यूटर की दुनिया में बदलाव की प्रतिक्रिया के रूप में थे, और मौजूदा मोनो कर्नेल को इन नई प्रणालियों के अनुकूल बनाने वाली कई चुनौतियों के लिए थे। नए डिवाइस ड्राइवर, प्रोटोकॉल स्टैक, फाइल सिस्टम और अन्य निम्न-स्तरीय सिस्टम हर समय विकसित किए जा रहे थे। यह कोड आम तौर पर मोनोलिथिक कर्नेल में स्थित था, और इस प्रकार काम करने के लिए काफी काम और सावधान कोड प्रबंधन की आवश्यकता थी। माइक्रोकर्नेल को इस विचार के साथ विकसित किया गया था कि इन सभी सेवाओं को उपयोगकर्ता-अंतरिक्ष कार्यक्रमों के रूप में लागू किया जाएगा, किसी भी अन्य की तरह, उन्हें अखंड रूप से काम करने की अनुमति दी जाएगी और किसी भी अन्य कार्यक्रम की तरह शुरू और बंद कर दिया जाएगा। यह न केवल इन सेवाओं पर अधिक आसानी से काम करने की अनुमति देगा, बल्कि अनपेक्षित साइड इफेक्ट के बारे में चिंता किए बिना इसे ठीक से ट्यून करने की अनुमति देने के लिए कर्नेल कोड को भी अलग कर देगा। इसके अलावा, यह पूरी तरह से नए ऑपरेटिंग सिस्टम को एक सामान्य कोर पर निर्मित करने की अनुमति देगा, जिससे OS अनुसंधान में सहायता मिलेगी।

1980 के दशक में माइक्रोकर्नेल एक बहुत ही चर्चित विषय था जब पहला प्रयोग करने योग्य स्थानीय क्षेत्र नेटवर्क पेश किया जा रहा था।[citation needed]. AmigaOS Exec (Amiga) कर्नेल एक प्रारंभिक उदाहरण था, जिसे 1986 में पेश किया गया था और सापेक्ष व्यावसायिक सफलता के साथ पीसी में उपयोग किया गया था। मेमोरी सुरक्षा की कमी, जिसे अन्य मामलों में एक दोष माना जाता है, ने इस कर्नेल को बहुत उच्च संदेश-पासिंग प्रदर्शन करने की अनुमति दी क्योंकि इसे उपयोगकर्ता-अंतरिक्ष कार्यक्रमों के बीच संदेशों का आदान-प्रदान करते समय डेटा कॉपी करने की आवश्यकता नहीं थी।[9]

वही तंत्र जो कर्नेल को उपयोगकर्ता स्थान में वितरित करने की अनुमति देता है, सिस्टम को नेटवर्क लिंक पर वितरित करने की अनुमति देता है। रिचर्ड राशिद द्वारा बनाए गए पहले माइक्रोकर्नेल, विशेष रूप से मच (कर्नेल) का प्रदर्शन निराशाजनक साबित हुआ, लेकिन अंतर्निहित फायदे इतने महान दिखाई दिए कि यह 1990 के दशक के अंत में अनुसंधान की एक प्रमुख पंक्ति थी।[citation needed] हालाँकि, इस समय के दौरान नेटवर्किंग सिस्टम के संबंध में कंप्यूटर की गति बहुत बढ़ गई, और प्रदर्शन में नुकसान ने विकास के मामले में फायदे को खत्म कर दिया।[citation needed] मौजूदा सिस्टम को बेहतर प्रदर्शन के लिए अनुकूलित करने के लिए कई प्रयास किए गए, लेकिन ओवरहेड हमेशा काफी था और इनमें से अधिकांश प्रयासों के लिए यूजर-स्पेस प्रोग्राम को कर्नेल में वापस ले जाने की आवश्यकता थी। 2000 तक, अधिकांश बड़े पैमाने के मैक ओएस (कर्नेल) कर्नेल प्रयास समाप्त हो गए थे, हालांकि 2001 में जारी ऐप्पल का मैकोज़ अभी भी एक्सएनयू नामक एक संकर गिरी का उपयोग करता है, जो भारी संशोधित (हाइब्रिड) ओएसएफ/1 के मच कर्नेल (ओएसएफटीके 7.3 कर्नेल) को जोड़ता है। बीएसडी यूनिक्स से कोड के साथ,[10][11] और यह कर्नेल iOS, tvOS और watchOS में भी प्रयोग किया जाता है। Windows NT, Windows NT 3.1|NT 3.1 के साथ शुरू होकर और Windows 11 के साथ जारी है, एक हाइब्रिड कर्नेल डिज़ाइन का उपयोग करता है। As of 2012, मैक-आधारित जीएनयू हर्ड भी कार्यात्मक है और आर्क लिनक्स और डेबियन के परीक्षण संस्करणों में सम्मलित है।

यद्यपि माइक्रोकर्नेल पर प्रमुख कार्य बहुतहद तक समाप्त हो गया था, प्रयोगकर्ताओं ने विकास जारी रखा।[citation needed] इसके बाद से यह दिखाया गया है कि पहले के डिजाइनों की कई प्रदर्शन समस्याएं अवधारणा की मौलिक सीमा नहीं थीं, बल्कि इसके अतिरिक्त डिजाइनर की एकल-उद्देश्य प्रणालियों का उपयोग करने की इच्छा के कारण इनमें से कई सेवाओं को लागू करने की इच्छा थी।[citation needed] विधानसभा कोड सहित समस्या के लिए अधिक व्यावहारिक दृष्टिकोण का उपयोग करना और सॉफ़्टवेयर में सामान्य रूप से समर्थित अवधारणाओं को लागू करने के लिए प्रोसेसर पर भरोसा करना नाटकीय रूप से बेहतर प्रदर्शन के साथ माइक्रोकर्नेल की एक नई श्रृंखला का नेतृत्व करता है।

माइक्रोकर्नेल exokernel से निकटता से संबंधित हैं।[12] उनके पास हाइपरविजर के साथ भी बहुत कुछ है,[13] लेकिन बाद वाले न्यूनतम होने का कोई दावा नहीं करते हैं और आभासी मशीनों का समर्थन करने के लिए विशिष्ट हैं; L4 माइक्रोकर्नेल अक्सर हाइपरविजर क्षमता में उपयोग पाता है।

परिचय

आरंभिक ऑपरेटिंग सिस्टम गुठली अपेक्षाकृत छोटे थे, आंशिक रूप से क्योंकि कंप्यूटर मेमोरी सीमित थी। जैसे-जैसे कंप्यूटर की क्षमता बढ़ती गई, कर्नेल को नियंत्रित करने वाले उपकरणों की संख्या भी बढ़ती गई। यूनिक्स के शुरुआती इतिहास के दौरान, गुठली आम तौर पर छोटी थी, भले ही उनमें विभिन्न डिवाइस ड्राइवर और फाइल सिस्टम कार्यान्वयन शामिल थे। जब एड्रेस स्पेस 16 से बढ़कर 32 बिट हो गया, कर्नेल डिज़ाइन अब हार्डवेयर आर्किटेक्चर द्वारा बाधित नहीं था, और कर्नेल बड़े होने लगे।

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

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

अंतर-प्रक्रिया संचार

इंटर-प्रोसेस कम्युनिकेशन (IPC) कोई भी तंत्र है जो अलग-अलग प्रक्रियाओं को एक दूसरे के साथ संवाद करने की अनुमति देता है, आमतौर पर संदेश भेजकर। साझा मेमोरी, कड़ाई से परिभाषित, एक अंतर-प्रक्रिया संचार तंत्र भी है, लेकिन संक्षिप्त नाम IPC आमतौर पर केवल संदेश भेजने को संदर्भित करता है, और यह बाद वाला है जो विशेष रूप से माइक्रोकर्नेल के लिए प्रासंगिक है। IPC ऑपरेटिंग सिस्टम को कई छोटे प्रोग्रामों से निर्मित करने की अनुमति देता है जिन्हें सर्वर कहा जाता है, जो सिस्टम पर अन्य प्रोग्रामों द्वारा उपयोग किए जाते हैं, जिन्हें IPC के माध्यम से लागू किया जाता है। पेरिफेरल हार्डवेयर के लिए अधिकांश या सभी समर्थन इस तरह से नियंत्रित किया जाता है, जिसमें डिवाइस ड्राइवर, नेटवर्क प्रोटोकॉल स्टैक, फाइल सिस्टम, ग्राफिक्स आदि के लिए सर्वर होते हैं।

IPC तुल्यकालिक या अतुल्यकालिक हो सकता है। अतुल्यकालिक IPC नेटवर्क संचार के अनुरूप है: प्रेषक एक संदेश भेजता है और निष्पादन जारी रखता है। संदेश की उपलब्धता के लिए प्राप्तकर्ता जाँच (मतदान (कंप्यूटर विज्ञान)) करता है, या किसी अधिसूचना तंत्र के माध्यम से उसे सतर्क किया जाता है। अतुल्यकालिक IPC के लिए आवश्यक है कि कर्नेल संदेशों के लिए बफ़र्स और कतारें बनाए रखे, और बफ़र ओवरफ्लो से संबंधित हो; इसके लिए संदेशों की दोहरी प्रतिलिपि (कर्नेल को प्रेषक और रिसीवर को कर्नेल) की भी आवश्यकता होती है। सिंक्रोनस IPC में, पहला पक्ष (प्रेषक या रिसीवर) तब तक ब्लॉक करता है जब तक कि दूसरा पक्ष IPC को निष्पादित करने के लिए तैयार नहीं हो जाता। इसके लिए बफ़रिंग या कई प्रतियों की आवश्यकता नहीं होती है, लेकिन निहित मिलन स्थल प्रोग्रामिंग को मुश्किल बना सकता है। अधिकांश प्रोग्रामर एसिंक्रोनस सेंड और सिंक्रोनस रिसीव पसंद करते हैं।

पहली पीढ़ी के माइक्रोकर्नेल आमतौर पर सिंक्रोनस के साथ-साथ एसिंक्रोनस आईपीसी का समर्थन करते थे, और खराब आईपीसी प्रदर्शन से ग्रस्त थे। जोचेन लिडटके ने इस खराब प्रदर्शन के लिए आईपीसी तंत्र के डिजाइन और कार्यान्वयन को अंतर्निहित कारण माना। अपने L4 माइक्रोकर्नेल परिवार में उन्होंने उन तरीकों का बीड़ा उठाया है जो परिमाण के क्रम से IPC की लागत को कम करते हैं।[14] इनमें एक IPC सिस्टम कॉल सम्मलित है जो एक भेजने के साथ-साथ एक प्राप्त ऑपरेशन का समर्थन करता है, सभी IPC को समकालिक बनाता है, और रजिस्टरों में जितना संभव हो उतना डेटा पास करता है। इसके अतिरिक्त, Liedtke ने डायरेक्ट प्रोसेस स्विच की अवधारणा पेश की, जहाँ IPC निष्पादन के दौरान एक (अपूर्ण) संदर्भ स्विच प्रेषक से सीधे रिसीवर तक किया जाता है। यदि, जैसा कि L4 में है, संदेश का भाग या पूरा भाग रजिस्टरों में पारित किया जाता है, तो यह बिना किसी प्रतिलिपि के संदेश के इन-रजिस्टर भाग को स्थानांतरित कर देता है। इसके अतिरिक्त, शेड्यूलर को कॉल करने के ओवरहेड से बचा जाता है; यह आम मामले में विशेष रूप से फायदेमंद है जहाँ आईपीसी का प्रयोग दुरस्तह प्रकिया कॉल (आरपीसी) प्रकार के फैशन में क्लाइंट द्वारा सर्वर को आमंत्रित करने के लिए किया जाता है। एक अन्य अनुकूलन, जिसे लेज़ी शेड्यूलिंग कहा जाता है, IPC के दौरान तैयार कतार में IPC के दौरान ब्लॉक होने वाले थ्रेड्स को छोड़कर IPC के दौरान ट्रैवर्सिंग शेड्यूलिंग कतारों से बचता है। एक बार अनुसूचक के आह्वान के बाद, यह ऐसे धागों को उपयुक्त प्रतीक्षा कतार में ले जाता है। जैसा कि कई स्थितियों में अगले अनुसूचक आह्वान से पहले एक थ्रेड अनब्लॉक हो जाता है, यह दृष्टिकोण महत्वपूर्ण कार्य बचाता है। इसी तरह के दृष्टिकोण को QNX और MINIX 3 द्वारा अपनाया गया है।[citation needed] प्रयोगों की एक श्रृंखला में, चेन और बरशाद ने मोनोलिथिक प्रतिशोध के स्मृति चक्र प्रति निर्देश (MCPI) की तुलना माइक्रोकर्नेल मच (कर्नेल) के साथ की, जो उपयोगकर्ता स्थान में चल रहे 4.3BSD यूनिक्स सर्वर के साथ संयुक्त है। उनके परिणामों ने उच्च MCPI द्वारा Mach के खराब प्रदर्शन की व्याख्या की और प्रदर्शित किया कि IPC अकेले सिस्टम ओवरहेड के लिए ज़िम्मेदार नहीं है, यह सुझाव देते हुए कि IPC पर विशेष रूप से केंद्रित अनुकूलन का सीमित प्रभाव होगा।[15] लिडटके ने बाद में चेन और बरशाद के परिणामों को परिष्कृत करते हुए यह अवलोकन किया कि अल्ट्रिक्स और मैक एमसीपीआई के बीच अंतर का बड़ा हिस्सा क्षमता सीपीयू कैश#कैश-मिस|कैश-मिसेज के कारण होता है और यह निष्कर्ष निकाला कि कैश वर्किंग सेट को काफी कम कर देता है एक माइक्रोकर्नेल समस्या का समाधान करेगा।[16]

क्लाइंट-सर्वर सिस्टम में, अधिकांश संचार अनिवार्य रूप से सिंक्रोनस होते हैं, भले ही एसिंक्रोनस प्रिमिटिव का उपयोग करते हुए, जैसा कि विशिष्ट ऑपरेशन एक क्लाइंट है जो सर्वर को इनवॉइस करता है और फिर उत्तर की प्रतीक्षा करता है। जैसा कि यह खुद को और अधिक कुशल कार्यान्वयन के लिए उधार देता है, अधिकांश माइक्रोकर्नेल आमतौर पर L4 के नेतृत्व का पालन करते हैं और केवल एक तुल्यकालिक IPC आदिम प्रदान करते हैं। अतुल्यकालिक IPC को सहायक सूत्र का उपयोग करके शीर्ष पर लागू किया जा सकता है। हालांकि, अनुभव ने दिखाया है कि सिंक्रोनस आईपीसी की उपयोगिता संदिग्ध है: सिंक्रोनस आईपीसी परिणामस्वरूप सिंक्रनाइज़ेशन जटिलताओं के साथ अन्यथा सरल सिस्टम पर एक बहु-थ्रेडेड डिज़ाइन को बाध्य करता है। इसके अलावा, एक RPC- जैसा सर्वर इनवोकेशन क्लाइंट और सर्वर को अनुक्रमित करता है, जिसे अलग-अलग कोर पर चलने पर टाला जाना चाहिए। वाणिज्यिक उत्पादों में परिनियोजित L4 के संस्करणों ने अतुल्यकालिक संचार को बेहतर समर्थन देने के लिए एक अतुल्यकालिक अधिसूचना तंत्र को जोड़ना आवश्यक पाया है। यह संकेत (कंप्यूटिंग) जैसा तंत्र डेटा नहीं रखता है और इसलिए कर्नेल द्वारा बफरिंग की आवश्यकता नहीं होती है। IPC के दो रूप होने के बावजूद, उन्होंने न्यूनतमता के सिद्धांत का उल्लंघन किया है। L4 के अन्य संस्करण पूरी तरह से अतुल्यकालिक IPC में बदल गए हैं।[17]

जैसा कि सिंक्रोनस IPC पहले पक्ष को तब तक ब्लॉक करता है जब तक कि दूसरा तैयार न हो, अप्रतिबंधित उपयोग आसानी से गतिरोध का कारण बन सकता है। इसके अलावा, एक ग्राहक अनुरोध भेजकर और कभी भी उत्तर प्राप्त करने का प्रयास नहीं करके सर्वर पर सेवा से इनकार का हमला आसानी से कर सकता है। इसलिए, सिंक्रोनस IPC को अनिश्चितकालीन ब्लॉकिंग को रोकने के लिए एक साधन प्रदान करना चाहिए। कई माइक्रोकर्नेल IPC कॉल्स पर टाइमआउट (दूरसंचार) प्रदान करते हैं, जो ब्लॉकिंग समय को सीमित करते हैं। व्यवहार में, समझदार टाइमआउट मान चुनना मुश्किल है, और सिस्टम लगभग अनिवार्य रूप से क्लाइंट के लिए अनंत टाइमआउट और सर्वर के लिए शून्य टाइमआउट का उपयोग करते हैं। नतीजतन, प्रवृत्ति मनमाने ढंग से टाइमआउट प्रदान करने की ओर नहीं है, बल्कि केवल एक झंडा है जो इंगित करता है कि यदि भागीदार तैयार नहीं है तो आईपीसी तुरंत विफल हो जाना चाहिए। यह दृष्टिकोण प्रभावी रूप से शून्य और अनंत के दो टाइमआउट मानों का विकल्प प्रदान करता है। L4 और MINIX के हाल के संस्करण इस पथ से नीचे चले गए हैं (L4 के पुराने संस्करण टाइमआउट का उपयोग करते हैं)। QNX क्लाइंट को मैसेज सेंड कॉल के हिस्से के रूप में रिप्लाई बफ़र निर्दिष्ट करने की आवश्यकता के द्वारा समस्या से बचा जाता है। जब सर्वर रिप्लाई करता है तो कर्नेल डेटा को क्लाइंट के बफर में कॉपी कर देता है, क्लाइंट को स्पष्ट रूप से प्रतिक्रिया प्राप्त करने के लिए इंतजार किए बिना। [18]






सर्वर

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

एक सामान्य-उद्देश्य वाले माइक्रोकर्नल के लिए सर्वरों के एक बुनियादी सेट में फाइल सिस्टम सर्वर, डिवाइस ड्राइवर सर्वर, नेटवर्किंग सर्वर, प्रदर्शन सर्वर और यूजर इंटरफेस डिवाइस सर्वर शामिल हैं। सर्वर का यह सेट (QNX से तैयार किया गया) मोटे तौर पर यूनिक्स मोनोलिथिक कर्नेल द्वारा प्रदान की जाने वाली सेवाओं का सेट प्रदान करता है। आवश्यक सर्वर सिस्टम स्टार्टअप पर शुरू होते हैं और सामान्य एप्लिकेशन प्रोग्रामों को फाइल, नेटवर्क और डिवाइस एक्सेस जैसी सेवाएं प्रदान करते हैं। उपयोगकर्ता अनुप्रयोग के वातावरण में चलने वाले ऐसे सर्वरों के साथ, सर्वर विकास कर्नेल विकास के लिए आवश्यक बिल्ड-एंड-बूट प्रक्रिया के बजाय सामान्य अनुप्रयोग विकास के समान है।

इसके अतिरिक्त, कई क्रैश केवल क्रैश-ओनली सॉफ्टवेयर द्वारा ठीक किए जा सकते हैं। हालांकि, विफल सर्वर के साथ सिस्टम स्थिति का हिस्सा खो गया है, इसलिए इस दृष्टिकोण को विफलता से निपटने के लिए अनुप्रयोगों की आवश्यकता होती है। एक अच्छा उदाहरण इंटरनेट प्रोटोकॉल सूट के लिए जिम्मेदार एक सर्वर है। टीसीपी/आईपी कनेक्शन: यदि यह सर्वर फिर से शुरू होता है, तो एप्लिकेशन एक खोए हुए कनेक्शन का अनुभव करेंगे, जो नेटवर्क सिस्टम में एक सामान्य घटना है। अन्य सेवाओं के लिए, विफलता की उम्मीद कम है और इसके लिए एप्लिकेशन कोड में बदलाव की आवश्यकता हो सकती है। क्यूएनएक्स के लिए, क्यूएनएक्स उच्च उपलब्धता टूलकिट के रूप में पुनः आरंभ करने की क्षमता प्रदान की जाती है।[19]






डिवाइस ड्राइवर

डिवाइस ड्राइवर प्रायः प्रत्यक्ष मेमोरी एक्सेस (डीएमए) करते हैं, और इसलिए विभिन्न कर्नेल डेटा संरचनाओं सहित भौतिक मेमोरी के मनमाने स्थानों पर लिख सकते हैं। इसलिए ऐसे ड्राइवरों पर भरोसा किया जाना चाहिए। यह एक आम ग़लतफ़हमी है कि इसका मतलब है कि उन्हें कर्नेल का हिस्सा होना चाहिए। वास्तव में, एक ड्राइवर कर्नेल का हिस्सा होने के कारण स्वाभाविक रूप से अधिक या कम भरोसेमंद नहीं होता है।

उपयोक्ता स्थान में एक डिवाइस ड्राइवर चलाने के दौरान आवश्यक रूप से एक दुर्व्यवहार करने वाले ड्राइवर को होने वाली क्षति को कम नहीं करता है, व्यवहार में यह बग्गी (दुर्भावनापूर्ण के अतिरिक्त) ड्राइवरों की उपस्थिति में सिस्टम स्थिरता के लिए फायदेमंद है: ड्राइवर कोड द्वारा ही मेमोरी-एक्सेस उल्लंघन ( डिवाइस के विपरीत) अभी भी मेमोरी-मैनेजमेंट हार्डवेयर द्वारा पकड़ा जा सकता है। इसके अतिरिक्त, कई डिवाइस डीएमए-सक्षम नहीं हैं, उनके ड्राइवरों को उपयोगकर्ता स्थान में चलाकर अविश्वसनीय बनाया जा सकता है। हाल ही में, कंप्यूटरों की बढ़ती संख्या में IOMMUs की सुविधा है, जिनमें से कई का उपयोग डिवाइस की भौतिक मेमोरी तक पहुंच को प्रतिबंधित करने के लिए किया जा सकता है।[20] ऐतिहासिक रूप से, ड्राइवरों को कोई समस्या नहीं थी, क्योंकि उपकरणों की संख्या वैसे भी छोटी और भरोसेमंद थी, इसलिए उन्हें कर्नेल में रखने से डिज़ाइन सरल हो गया और संभावित प्रदर्शन समस्याओं से बचा गया। इसने यूनिक्स की पारंपरिक ड्राइवर-इन-द-कर्नेल शैली को जन्म दिया, रेफरी नाम = लायंस बुक >Lions, John (1 August 1977). स्रोत कोड के साथ यूनिक्स छठे संस्करण पर लायंस की टिप्पणी. Peer-To-Peer Communications. ISBN 978-1-57398-013-5.</ रेफ> लिनक्स, और विंडोज एनटी। विभिन्न प्रकार के बाह्य उपकरणों के प्रसार के साथ, ड्राइवर कोड की मात्रा में वृद्धि हुई और आधुनिक ऑपरेटिंग सिस्टम में कोड आकार में कर्नेल पर हावी हो गया।

आवश्यक घटक और न्यूनतम

जैसा कि एक माइक्रोकर्नेल को शीर्ष पर मनमाने ढंग से ऑपरेटिंग सिस्टम सेवाओं के निर्माण की अनुमति देनी चाहिए, इसे कुछ मुख्य कार्यक्षमता प्रदान करनी चाहिए। कम से कम, इसमें सम्मलित हैं:

  • स्मृति सुरक्षा के प्रबंधन के लिए आवश्यक पता स्थान से निपटने के लिए कुछ तंत्र
  • सीपीयू आवंटन, सामान्यतः थ्रेड (कंप्यूटिंग) या अनुसूचक सक्रियण को प्रबंधित करने के लिए कुछ निष्पादन अमूर्त
  • इंटर-प्रोसेस कम्युनिकेशन, अपने स्वयं के एड्रेस स्पेस में चल रहे सर्वर को इनवॉइस करने के लिए आवश्यक है

यह न्यूनतम डिजाइन ब्रिनच हैनसेन के RC 4000 मल्टीप्रोग्रामिंग सिस्टम और आईबीएम के वीएम (ऑपरेटिंग सिस्टम) के हाइपरवाइजर द्वारा अग्रणी था। इसके बाद से लिडटके के न्यूनतम सिद्धांत में इसे औपचारिक रूप दिया गया है:

एक अवधारणा को माइक्रोकर्नल के अंदर तभी सहन किया जाता है जब इसे कर्नेल के बाहर ले जाया जाता है, यानी, प्रतिस्पर्धी कार्यान्वयन की अनुमति, सिस्टम की आवश्यक कार्यक्षमता के कार्यान्वयन को रोक देगा।[16]</ब्लॉककोट>

यूजरमोड प्रोग्राम में बाकी सब कुछ किया जा सकता है, हालांकि कुछ प्रोसेसर आर्किटेक्चर पर उपयोगकर्ता प्रोग्राम के रूप में कार्यान्वित डिवाइस ड्राइवर को I/O हार्डवेयर तक पहुंचने के लिए विशेष विशेषाधिकार की आवश्यकता होती है।

न्यूनता सिद्धांत से संबंधित, और माइक्रोकर्नेल डिज़ाइन के लिए समान रूप से महत्वपूर्ण, तंत्र और नीति का पृथक्करण है, यह वह है जो न्यूनतम कर्नेल के शीर्ष पर मनमाना सिस्टम के निर्माण को सक्षम बनाता है। कर्नेल में निर्मित कोई भी नीति उपयोक्ता स्तर पर अधिलेखित नहीं की जा सकती है और इसलिए माइक्रोकर्नेल की व्यापकता को सीमित करती है।[12]उपयोगकर्ता-स्तर के सर्वरों में लागू की गई नीति को सर्वरों को बदलकर बदला जा सकता है (या समान सेवाओं की पेशकश करने वाले प्रतिस्पर्धी सर्वरों के बीच एप्लिकेशन को चुनने दिया जा सकता है)।

दक्षता के लिए, अधिकांश माइक्रोकर्नेल में अनुसूचक होते हैं और न्यूनतम सिद्धांत और नीति-तंत्र पृथक्करण के सिद्धांत का उल्लंघन करते हुए टाइमर का प्रबंधन करते हैं।

माइक्रोकर्नेल-आधारित सिस्टम के स्टार्ट अप (बूटिंग) के लिए डिवाइस ड्राइवर की आवश्यकता होती है, जो कर्नेल का हिस्सा नहीं होते हैं। सामान्यतः इसका मतलब है कि वे बूट छवि में कर्नेल के साथ पैक किए गए हैं, और कर्नेल बूटस्ट्रैप प्रोटोकॉल का समर्थन करता है जो परिभाषित करता है कि ड्राइवर कैसे स्थित हैं और शुरू हुए हैं; यह L4 माइक्रोकर्नेल परिवार की पारंपरिक बूटस्ट्रैप प्रक्रिया है। कुछ माइक्रोकर्नेल कर्नेल के अंदर कुछ प्रमुख ड्राइवरों को रखकर इसे सरल बनाते हैं (न्यूनतम सिद्धांत का उल्लंघन करते हुए), लिंक्सओएस और मूल मिनिक्स इसके उदाहरण हैं। कुछ बूटिंग को आसान बनाने के लिए कर्नेल में फ़ाइल सिस्टम भी सम्मलित करते हैं। ए माइक्रोकर्नेल-आधारित सिस्टम मल्टीबूट संगत बूट लोडर के माध्यम से बूट हो सकता है। इस तरह के सिस्टम सामान्यतः प्रारंभिक बूटस्ट्रैप बनाने या बूटस्ट्रैपिंग जारी रखने के लिए OS इमेज को माउंट करने के लिए स्टेटिकली-लिंक्ड सर्वर को लोड करते हैं।

माइक्रोकर्नेल का एक प्रमुख घटक एक अच्छी इंटर-प्रोसेस संचार प्रणाली और वर्चुअल-मेमोरी-मैनेजर डिज़ाइन है जो पेज-फ़ॉल्ट हैंडलिंग को लागू करने और सुरक्षित तरीके से यूजरमोड सर्वर में स्वैप करने की अनुमति देता है। चूंकि सभी सेवाओं को यूजरमोड प्रोग्राम द्वारा निष्पादित किया जाता है, कार्यक्रमों के बीच संचार के कुशल साधन आवश्यक हैं, अखंड गुठली की तुलना में कहीं अधिक। IPC प्रणाली का डिज़ाइन एक माइक्रोकर्नेल बनाता या तोड़ता है। प्रभावी होने के लिए, IPC सिस्टम में न केवल कम ओवरहेड होना चाहिए, बल्कि CPU शेड्यूलिंग के साथ भी अच्छी तरह से इंटरैक्ट करना चाहिए।

प्रदर्शन

अधिकांश मुख्यधारा के प्रोसेसर पर, एक मोनोलिथिक प्रणाली की तुलना में एक माइक्रोकर्नेल-आधारित प्रणाली में एक सेवा प्राप्त करना स्वाभाविक रूप से अधिक महंगा है।[12]अखंड प्रणाली में, सेवा एकल सिस्टम कॉल द्वारा प्राप्त की जाती है, जिसके लिए दो मोड स्विच (प्रोसेसर की रिंग (कंप्यूटर सुरक्षा) या सीपीयू मोड में परिवर्तन) की आवश्यकता होती है। माइक्रोकर्नेल-आधारित प्रणाली में, एक सर्वर को IPC संदेश भेजकर और सर्वर से दूसरे IPC संदेश में परिणाम प्राप्त करके सेवा प्राप्त की जाती है। यदि ड्राइवरों को प्रक्रियाओं के रूप में कार्यान्वित किया जाता है, या प्रक्रियाओं के रूप में कार्यान्वित किए जाने पर फ़ंक्शन कॉल के लिए इसके लिए एक संदर्भ स्विच की आवश्यकता होती है। इसके अतिरिक्त, वास्तविक डेटा को सर्वर और बैक में पास करने से अतिरिक्त कॉपी ओवरहेड हो सकता है, जबकि एक अखंड प्रणाली में कर्नेल सीधे क्लाइंट के बफ़र्स में डेटा तक पहुँच सकता है।

इसलिए प्रदर्शन माइक्रोकर्नेल सिस्टम में एक संभावित मुद्दा है। मच (कर्नेल) और कोरसोस जैसे पहली पीढ़ी के माइक्रोकर्नेल के अनुभव से पता चला है कि उन पर आधारित सिस्टम बहुत खराब प्रदर्शन करते हैं।[15]हालांकि, जोचेन लिडटके ने दिखाया कि मच की प्रदर्शन समस्याएं खराब डिजाइन और कार्यान्वयन, विशेष रूप से मैक के अत्यधिक सीपीयू कैश फुटप्रिंट का परिणाम थीं।[16]Liedtke ने अपने स्वयं के L4 माइक्रोकर्नेल के साथ प्रदर्शित किया कि सावधानीपूर्वक डिजाइन और कार्यान्वयन के माध्यम से, और विशेष रूप से न्यूनतम सिद्धांत का पालन करके, IPC की लागत को मच की तुलना में परिमाण के एक क्रम से अधिक कम किया जा सकता है। L4 का IPC प्रदर्शन अभी भी आर्किटेक्चर की एक श्रृंखला में अजेय है।[21][22][23]

जबकि ये परिणाम प्रदर्शित करते हैं कि पहली पीढ़ी के माइक्रोकर्नेल पर आधारित सिस्टम का खराब प्रदर्शन एल4 जैसे दूसरी पीढ़ी के कर्नेल के लिए प्रतिनिधि नहीं है, यह इस बात का कोई प्रमाण नहीं है कि माइक्रोकर्नेल आधारित सिस्टम को अच्छे प्रदर्शन के साथ बनाया जा सकता है। यह दिखाया गया है कि L4 में पोर्ट किया गया एक मोनोलिथिक लिनक्स सर्वर देशी लिनक्स पर केवल कुछ प्रतिशत ओवरहेड प्रदर्शित करता है।[24] हालांकि, इस तरह के एकल-सर्वर सिस्टम कुछ लाभ प्रदर्शित करते हैं, यदि कोई हो, तो माइक्रोकर्नेल को अलग-अलग सर्वरों अखंडता (ऑपरेटिंग सिस्टम) की कार्यक्षमता को संरचित करके प्रदान करना चाहिए।

कई वाणिज्यिक मल्टी-सर्वर सिस्टम मौजूद हैं, विशेष रूप से रीयल-टाइम ऑपरेटिंग सिस्टम | रीयल-टाइम सिस्टम क्यूएनएक्स और इंटीग्रिटी (ऑपरेटिंग सिस्टम)। उन मल्टीसर्वर सिस्टमों के लिए अखंड प्रणालियों के सापेक्ष प्रदर्शन की कोई व्यापक तुलना प्रकाशित नहीं की गई है। इसके अलावा, प्रदर्शन उन वाणिज्यिक प्रणालियों के लिए प्रमुख चिंता का विषय नहीं लगता है, जो इसके बजाय मज़बूती के लिए मज़बूती से त्वरित रुकावट प्रबंधन प्रतिक्रिया समय (QNX) और सादगी पर ज़ोर देते हैं। आईबीएम सॉमिल लाइनेक्स प्रोजेक्ट एक उच्च-प्रदर्शन मल्टीसर्वर ऑपरेटिंग सिस्टम बनाने का प्रयास था।[25] हालांकि, यह परियोजना कभी पूरी नहीं हुई।

इस बीच यह दिखाया गया है कि उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर गीगाबिट ईथरनेट जैसे उच्च-थ्रूपुट, उच्च-इंटरप्ट डिवाइस के लिए भी इन-कर्नेल ड्राइवरों के प्रदर्शन के करीब आ सकते हैं।[26] ऐसा प्रतीत होता है कि उच्च-प्रदर्शन बहु-सर्वर सिस्टम संभव हैं।






सुरक्षा

माइक्रोकर्नेल के सुरक्षा लाभों पर प्रायः चर्चा की जाती रही है।[27][28] सुरक्षा के संदर्भ में माइक्रो कर्नेल का न्यूनतम सिद्धांत, कुछ लोगों ने तर्क दिया है, कम से कम विशेषाधिकार के सिद्धांत का सीधा परिणाम है, जिसके अनुसार सभी कोड में केवल आवश्यक कार्यक्षमता प्रदान करने के लिए आवश्यक विशेषाधिकार होने चाहिए। न्यूनतमता के लिए आवश्यक है कि सिस्टम का विश्वसनीय कंप्यूटिंग बेस (TCB) न्यूनतम रखा जाए। चूंकि कर्नेल (कोड जो हार्डवेयर के विशेषाधिकार प्राप्त मोड में निष्पादित होता है) के पास किसी भी डेटा तक पहुंच नहीं है और इस प्रकार इसकी अखंडता या गोपनीयता का उल्लंघन कर सकता है, कर्नेल हमेशा टीसीबी का हिस्सा होता है। सुरक्षा-संचालित डिज़ाइन में इसे कम करना स्वाभाविक है।

परिणाम स्वरुप , माइक्रोकर्नेल डिज़ाइन का उपयोग उच्च-सुरक्षा अनुप्रयोगों के लिए डिज़ाइन किए गए सिस्टम के लिए किया गया है, जिसमें KeyKOS, अत्यंत विश्वसनीय ऑपरेटिंग सिस्टम और सैन्य सिस्टम सम्मलित हैं। वास्तव में उच्चतम आश्वासन स्तर (मूल्यांकन आश्वासन स्तर (ईएएल) 7) पर सामान्य मानदंड (सीसी) की एक स्पष्ट आवश्यकता है कि मूल्यांकन का लक्ष्य सरल हो, एक जटिल प्रणाली के लिए सच्ची विश्वसनीयता स्थापित करने की व्यावहारिक असंभवता की स्वीकृति। फिर से, सरल शब्द भ्रामक और खराब परिभाषित है। कम से कम रक्षा विभाग के भरोसेमंद कंप्यूटर सिस्टम मूल्यांकन मानदंड ने B3/A1 कक्षाओं में कुछ अधिक सटीक शब्दावली पेश की:

"The TCB shall [implement] complete, conceptually simple protection mechanisms with precisely defined semantics. Significant system engineering shall be directed toward minimizing the complexity of the TCB, as well as excluding from the TCB those modules that are not protection-critical."

— Department of Defense Trusted Computer System Evaluation Criteria

2018 में, एशिया-पैसिफिक सिस्टम्स कॉन्फ्रेंस में प्रस्तुत एक पेपर ने दावा किया कि उस समय लिनक्स कर्नेल के लिए सभी प्रकाशित महत्वपूर्ण सामान्य कमजोरियों और एक्सपोजर की जांच करके माइक्रोकर्नेल मोनोलिथिक कर्नेल की तुलना में सुरक्षित रूप से सुरक्षित थे। अध्ययन ने निष्कर्ष निकाला कि औपचारिक रूप से सत्यापित माइक्रोकर्नेल में 40% मुद्दे बिल्कुल भी नहीं हो सकते हैं, और केवल 4% मुद्दे ऐसी प्रणाली में पूरी तरह से असंतुलित रहेंगे।[29]


तीसरी पीढ़ी

माइक्रोकर्नेल पर हाल ही में किया गया कार्य कर्नेल API के औपचारिक विनिर्देशों, API के सुरक्षा गुणों और कार्यान्वयन शुद्धता के औपचारिक प्रमाण पर ध्यान केंद्रित कर रहा है। इसका पहला उदाहरण EROS API के सरलीकृत मॉडल के आधार पर EROS में परिरोध यांत्रिकी का गणितीय प्रमाण है।[30] हाल ही में (2007 में) मशीन-जाँच किए गए प्रमाणों के एक व्यापक सेट ने, L4 के एक संस्करण SEL4 के सुरक्षा मॉडल, के गुणों का प्रदर्शन किया था।[31][32][33]

SEL4 के मामले में, कार्यान्वयन का पूर्ण औपचारिक सत्यापन प्राप्त कर लिया गया है,[34]यानी एक गणितीय प्रमाण कि कर्नेल का कार्यान्वयन उसके औपचारिक विनिर्देश के अनुरूप है। यह एक गारंटी प्रदान करता है कि एपीआई के बारे में साबित गुण वास्तव में वास्तविक कर्नेल के लिए धारण करते हैं, आश्वासन की एक डिग्री जो सीसी ईएएल7 से भी आगे जाती है। इसके बाद एपीआई के सुरक्षा-प्रवर्तन गुणों के प्रमाण दिए गए, और एक प्रमाण यह प्रदर्शित करता है कि निष्पादन योग्य बाइनरी कोड सी कार्यान्वयन का सही अनुवाद है, जो टीसीबी से संकलक को बाहर ले जाता है। एक साथ लिया गया, ये सबूत कर्नेल के सुरक्षा गुणों का एंड-टू-एंड सबूत स्थापित करते हैं।[35]

उदाहरण

माइक्रोकर्नेल के कुछ उदाहरण हैं:

  • हेलेनोस
  • निनटेंडो स्विच सिस्टम सॉफ्टवेयर#प्रौद्योगिकी
  • L4 माइक्रोकर्नेल परिवार
  • मिनिक्स
  • फुकिया (ऑपरेटिंग सिस्टम)#कर्नेल

नैनोकर्नेल

नैनोकर्नेल या पिकोकर्नेल शब्द का ऐतिहासिक रूप से उल्लेख किया गया है:

  • एक कर्नेल जहां कर्नेल कोड की कुल मात्रा, यानी हार्डवेयर के विशेषाधिकार प्राप्त मोड में निष्पादित कोड बहुत छोटा है। पिकोकर्नेल शब्द का प्रयोग कभी-कभी छोटे आकार पर जोर देने के लिए किया जाता था। नैनोकर्नेल शब्द जोनाथन एस. शापिरो द्वारा पेपर नैनोकर्नेल आर्किटेक्चर। यह मच (कर्नेल) के लिए एक तिरस्कारपूर्ण प्रतिक्रिया थी, जो एक माइक्रोकर्नेल होने का दावा करती थी, जबकि शापिरो इसे मोनोलिथिक, अनिवार्य रूप से असंरचित, और इसे बदलने की मांग की गई प्रणालियों की तुलना में धीमा मानते थे। पिकोकर्नेल सिक्का सहित शब्द के बाद के पुन: उपयोग और प्रतिक्रिया से पता चलता है कि बिंदु काफी हद तक चूक गया था। नैनोकर्नेल और पिकोकर्नेल दोनों बाद में माइक्रोकर्नेल शब्द द्वारा व्यक्त किए गए समान अर्थ के लिए आए हैं।
  • एक ऑपरेटिंग सिस्टम के नीचे एक वर्चुअलाइजेशन परत, जिसे हाइपरविजर के रूप में अधिक सही ढंग से संदर्भित किया जाता है।
  • एक हार्डवेयर अमूर्त परत जो कर्नेल का निम्नतम-स्तर का हिस्सा बनाती है, कभी-कभी वास्तविक समय कंप्यूटिंग प्रदान करने के लिए उपयोग की जाती है | सामान्य ऑपरेटिंग सिस्टम के लिए वास्तविक समय की कार्यक्षमता, जैसे ऑपरेटिंग सिस्टम के लिए अनुकूली डोमेन पर्यावरण

कम से कम एक मामला ऐसा भी है जहां नैनोकर्नेल शब्द का उपयोग एक छोटे कर्नेल के लिए नहीं, बल्कि एक नैनोसेकंड क्लॉक रिज़ॉल्यूशन का समर्थन करने के लिए किया जाता है।[36]

इसने तीसरी पीढ़ी के माइक्रोकर्नेल के रूप में संदर्भित किया है, [34] एक सुरक्षा-उन्मुख एपीआई की विशेषता है जिसमें क्षमताओं द्वारा नियंत्रित संसाधन पहुंच, प्रथम श्रेणी की चिंता के रूप में वर्चुअलाइजेशन, कर्नेल संसाधन प्रबंधन के लिए उपन्यास दृष्टिकोण, [35] और उच्च प्रदर्शन के सामान्य लक्ष्य के अलावा औपचारिक विश्लेषण के लिए उपयुक्तता का एक डिजाइन लक्ष्य। उदाहरण हैं कोयोटोस, एसईएल4, नोवा,[36][37] रेडॉक्स और फिएस्को.ओसी.[36][38]

SEL4 के मामले में, कार्यान्वयन का पूर्ण औपचारिक सत्यापन हासिल कर लिया गया है, [34] यानी एक गणितीय प्रमाण है कि कर्नेल का कार्यान्वयन इसके औपचारिक विनिर्देश के अनुरूप है। यह एक गारंटी प्रदान करता है कि एपीआई के बारे में साबित गुण वास्तव में वास्तविक कर्नेल के लिए धारण करते हैं, आश्वासन की एक डिग्री जो सीसी ईएएल7 से भी आगे जाती है। इसके बाद एपीआई के सुरक्षा-प्रवर्तन गुणों के प्रमाण दिए गए, और एक प्रमाण यह प्रदर्शित करता है कि निष्पादन योग्य बाइनरी कोड सी कार्यान्वयन का सही अनुवाद है, जो टीसीबी से संकलक को बाहर ले जाता है। एक साथ लेने पर, ये प्रमाण कर्नेल के सुरक्षा गुणों का एक सिरे से अंत तक का प्रमाण स्थापित करते हैं। [39]






उदाहरण [edit]

माइक्रोकर्नेल के कुछ उदाहरण इस प्रकार हैं:

  • हेलेन OS
  • Horizon
  • L4 माइक्रोकर्नेल परिवार
  • मिनिक्स
  • जिक्रोन

नैनोकर्नेल [edit]

नैनोकर्नेल या पिकोकर्नेल शब्द का ऐतिहासिक रूप से उल्लेख किया गया है:

एक कर्नेल जहाँ कर्नेल कोड की कुल मात्रा, अर्थात् हार्डवेयर के विशेषाधिकृत मोड में निष्पादित कोड, बहुत छोटी होती है। पिकोकर्नेल शब्द का प्रयोग कभी-कभी और छोटे आकार पर जोर देने के लिए किया जाता था। नैनोकर्नेल शब्द को द कीकोस नैनोकर्नेल आर्किटेक्चर कागज पर जोनाथन एस. शापिरो द्वारा लिखा गया था। यह मार्च के लिए एक तिरस्कारपूर्ण प्रतिक्रिया थी, जो एक माइक्रोकर्नेल होने का दावा करती थी, जबकि शापिरो ने इसे मोनोलिथिक, अनिवार्य रूप से असंरचित और उन प्रणालियों की तुलना में धीमा माना जो इसे बदलने की मांग कर रहे थे। पिकोकर्नेल मुद्रा सहित शब्द के बाद के पुन: उपयोग और प्रतिक्रिया से पता चलता है कि बिंदु बहुत हद तक चूक गया था। नैनोकर्नेल और पिकोकर्नेल दोनों बाद में माइक्रोकर्नेल शब्द द्वारा व्यक्त किए गए समान अर्थ के लिए आए हैं।

एक ऑपरेटिंग सिस्टम के नीचे एक वर्चुअलाइजेशन परत, जिसे हाइपरविजर के रूप में अधिक सही ढंग से संदर्भित किया जाता है।

एक हार्डवेयर अमूर्त परत जो कर्नेल के निम्नतम स्तर का हिस्सा बनाती है, कभी-कभी सामान्य ऑपरेटिंग सिस्टम जैसे एडीओस को रीयल-टाइम कार्यक्षमता प्रदान करने के लिए उपयोग की जाती है।

कम से कम एक स्थिति ऐसी भी है जहाँ नैनोकर्नेल शब्द का प्रयोग एक छोटे कर्नेल के लिए नहीं, बल्कि एक नैनोसेकंड क्लॉक रेज़ोल्यूशन का समर्थन करने के लिए किया जाता है। [40]

यह भी देखें

संदर्भ

  1. Herder, Jorrit N. (23 February 2005). "एक ट्रू माइक्रोकर्नेल ऑपरेटिंग सिस्टम की ओर" (PDF). minix3.org. Retrieved 22 June 2015.
  2. पढ़ें "अधिक पढ़ें". Retrieved 20 December 2016. {{cite web}}: Check |url= value (help)
  3. "2002 कंप्यूटर पायनियर पुरस्कार प्राप्तकर्ता". IEEE Computer Society. Retrieved 13 September 2016.
  4. Brinch Hansen, Per (2004). एक प्रोग्रामर की कहानी: एक कंप्यूटर पायनियर का जीवन. Retrieved 13 September 2016.
  5. Brinch Hansen, Per (April 1969). आरसी 4000 सॉफ्टवेयर: मल्टीप्रोग्रामिंग सिस्टम (PDF) (Technical report). Regnecentralen. Retrieved 13 September 2016.
  6. Brinch Hansen, Per (1970). "मल्टीप्रोग्रामिंग ऑपरेटिंग सिस्टम का न्यूक्लियस" (PDF). Communications of the ACM. 13 (4): 238–250. CiteSeerX 10.1.1.105.4204. doi:10.1145/362258.362278. S2CID 9414037.
  7. .Wulf, William; Cohen, Ellis; Corwin, William; Jones, Anita; Levin, Roy; Pierson, C.; Pollack, Fred (June 1974). "हाइड्रा: मल्टीप्रोसेसर ऑपरेटिंग सिस्टम का कर्नेल". Communications of the ACM. 17 (6): 337–345. doi:10.1145/355616.364017. S2CID 8011765.
  8. Rashid, Richard; Robertson, George (December 1981). एक्सेंट: एक संचार उन्मुख नेटवर्क ऑपरेटिंग सिस्टम कर्नेल. SOSP '81 Proceedings of the eighth ACM symposium on Operating systems principles. Pacific Grove, California, USA. pp. 64–75. doi:10.1145/800216.806593.
  9. Sassenrath, Carl (1986). अमिगा रोम कर्नेल संदर्भ मैनुअल. Exec.{{cite book}}: CS1 maint: location missing publisher (link)
  10. Jim Magee. डब्ल्यूडब्ल्यूडीसी 2000 सत्र 106 - मैक ओएस एक्स: कर्नेल. 14 minutes in. Archived from the original on 11 December 2021.
  11. "UNIX/Linux अनुप्रयोगों को Mac OS X में पोर्ट करना". Apple. Retrieved 26 April 2011.
  12. 12.0 12.1 12.2 Liedtke, Jochen (September 1996). "रियल माइक्रोकर्नेल की ओर". Communications of the ACM. 39 (9): 70–77. doi:10.1145/234215.234473. S2CID 2867357.
  13. Heiser, Gernot; Uhlig, Volkmar; LeVasseur, Joshua (January 2006). "क्या वर्चुअल-मशीन मॉनिटर्स माइक्रोकर्नेल सही हैं?". ACM SIGOPS Operating Systems Review. ACM. 40 (1): 95–99. doi:10.1145/1113361.1113363. S2CID 7414062.
  14. Liedtke, Jochen (December 1993). कर्नेल डिज़ाइन द्वारा IPC में सुधार. 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 175–88. CiteSeerX 10.1.1.40.1293.
  15. 15.0 15.1 Chen, J. Bradley; Bershad, Brian N. (December 1993). मेमोरी सिस्टम के प्रदर्शन पर ऑपरेटिंग सिस्टम संरचना का प्रभाव (PDF). SOSP '93 Proceedings of the fourteenth ACM symposium on Operating systems principles. Asheville, NC, USA. pp. 120–133. doi:10.1145/168619.168629.
  16. 16.0 16.1 16.2 Liedtke, Jochen (December 1995). µ-कर्नेल निर्माण पर. SOSP '95 Proceedings of the fifteenth ACM symposium on Operating systems principles. Copper Mountain Resort, CO, USA. pp. 237–250. doi:10.1145/224056.224075.
  17. Elphinstone, Kevin; Heiser, Gernot (November 2013). L3 से seL4 तक: L4 माइक्रोकर्नेल के 20 वर्षों में हमने क्या सीखा?. SOSP '13 Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. Farmington, PA, USA. pp. 133–150. doi:10.1145/2517349.2522720.
  18. "तुल्यकालिक संदेश पासिंग". Retrieved 14 July 2019.
  19. "क्यूएनएक्स उच्च उपलब्धता टूलकिट" (PDF). Archived from the original (PDF) on 24 August 2005.
  20. Wong, William (27 April 2007). "I/O, I/O, इट्स ऑफ टू वर्चुअल वर्क वी गो". Electronic Design. Retrieved 8 June 2009.</ रेफ> यह उपयोगकर्ता-मोड ड्राइवरों को अविश्वसनीय बनने की भी अनुमति देता है। उपयोगकर्ता-मोड ड्राइवर वास्तव में माइक्रोकर्नेल से पहले के हैं। मिशिगन टर्मिनल सिस्टम (MTS), 1967 में, यूजर स्पेस ड्राइवर्स (इसकी फाइल सिस्टम सपोर्ट सहित) को सपोर्ट करता है, जो उस क्षमता के साथ डिजाइन किया जाने वाला पहला ऑपरेटिंग सिस्टम है। रेफरी>Alexander, Michael T. (1971). "मिशिगन टर्मिनल सिस्टम का संगठन और विशेषताएं". Proceedings of the November 16–18, 1971, Fall Joint Computer Conference. 40: 589–591. doi:10.1145/1478873.1478951. S2CID 14614148.
  21. Liedtke, Jochen; Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, Nayeem; Jaeger, Trent (May 1997). प्राप्त IPC प्रदर्शन (अभी भी विस्तारणीयता के लिए नींव). 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. pp. 28–31.
  22. Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). इटेनियम-एक प्रणाली कार्यान्वयनकर्ता की कहानी. USENIX Annual Technical Conference. Annaheim, CA, USA. pp. 264–278.
  23. van Schaik, Carl; Heiser, Gernot (January 2007). एआरएम और खंडित वास्तुकला पर उच्च-प्रदर्शन माइक्रोकर्नेल और वर्चुअलाइजेशन. 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. pp. 11–21. Archived from the original on 26 April 2007. Retrieved 1 April 2007.
  24. Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian (October 1997). "μ-कर्नेल-आधारित सिस्टम का प्रदर्शन". Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles. 31 (5): 66–77. doi:10.1145/268998.266660. ISBN 0-89791-916-5. S2CID 1706253.
  25. Gefflaut, Alain; Jaeger, Trent; Park, Yoonho; Liedtke, Jochen; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; et al. (2000). सॉमिल मल्टीसर्वर दृष्टिकोण. 9th ACM SIGOPS European Workshop. Kolding, Denmark. pp. 109–114. CiteSeerX 10.1.1.25.8376.
  26. Leslie, Ben; Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). "उपयोगकर्ता-स्तरीय डिवाइस ड्राइवर: प्रदर्शन हासिल किया". Journal of Computer Science and Technology. 20 (5): 654–664. doi:10.1007/s11390-005-0654-4. S2CID 1121537.
  27. Tanenbaum, Andrew S. "तनेनबौम-टोरवाल्ड्स बहस, भाग II".
  28. Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
  29. Biggs, Simon; Lee, Damon; Heiser, Gernot (2018). "जूरी है: मोनोलिथिक OS डिज़ाइन त्रुटिपूर्ण है: माइक्रोकर्नेल-आधारित डिज़ाइन सुरक्षा में सुधार करते हैं". Proceedings of the 9th Asia-Pacific Workshop on Systems. Jeju Island, Republic of Korea: Association for Computing Machinery. pp. 1–7. doi:10.1145/3265723.3265733.
  30. Shapiro, Jonathan S.; Weber, Samuel. Verifying the EROS Confinement Mechanism. IEEE Conference on Security and Privacy. Archived from the original on 3 March 2016.
  31. Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). SEL4 माइक्रोकर्नेल का सत्यापित सुरक्षा मॉडल. submitted for publication.
  32. Cite error: Invalid <ref> tag; no text was provided for refs named TUD
  33. Lackorzynski, Adam; Warg, Alexander (March 2009). टेमिंग सबसिस्टम - L4 में यूनिवर्सल रिसोर्स एक्सेस कंट्रोल के रूप में क्षमताएं. IIES'09: Second Workshop on Isolation and Integration in Embedded Systems. Nuremberg, Germany. CiteSeerX 10.1.1.629.9845.
  34. Cite error: Invalid <ref> tag; no text was provided for refs named Klein_EHACDEEKNSTW_09
  35. Klein, Gerwin; Andronick, June; Elphinstone, Kevin; Murray, Toby; Sewell, Thomas; Kolanski, Rafal; Heiser, Gernot (February 2014). "OS माइक्रोकर्नेल का व्यापक औपचारिक सत्यापन". ACM Transactions on Computer Systems. 32 (1): 2:1–2:70. doi:10.1145/2560537. S2CID 4474342.
  36. David L. Mills and Poul-Henning Kamp (28 November 2000). "नैनो कर्नेल" (PDF). Retrieved 28 August 2017.

अग्रिम पठन

यह:कर्नेल#माइक्रोकर्नेल फाई:कायट्टोर्जेस्टेलमैन यदिन#मिक्रोयडिन