यह आलेख बताता है कि ऑपरेटिंग सिस्टम का कर्नेल भौतिक मेमोरी फ़्रेम तक कैसे पहुंच सकता है। हम भौतिक लोगों को आभासी पतों को परिवर्तित करने के लिए फ़ंक्शन का अध्ययन करेंगे। हम यह भी पता लगाएंगे कि पेज टेबल में नए मैपिंग कैसे बनाएं।

यह ब्लॉग GitHub पर पोस्ट किया गया है । यदि आपके कोई प्रश्न या समस्याएं हैं, तो वहां संबंधित टिकट खोलें। लेख के सभी स्रोत यहां दिए गए हैं ।

परिचय

पिछले लेख से, हमने पेजिंग मेमोरी के सिद्धांतों और x86_64 पर चार-स्तरीय पृष्ठ तालिकाओं के बारे में सीखा। हमने यह भी पाया कि लोडर पहले से ही हमारे कर्नेल के लिए पृष्ठ तालिका पदानुक्रम सेट करता है, इसलिए कर्नेल वर्चुअल पतों पर चलता है। इससे सुरक्षा में सुधार होता है, लेकिन यह समस्या उत्पन्न होती है: पृष्ठ तालिका प्रविष्टियों या CR3 में संग्रहीत वास्तविक भौतिक पतों का उपयोग कैसे करें?

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

निर्भरता अद्यतन

काम करने के लिए, आपको x86_64 संस्करण 0.4.0 या बाद की आवश्यकता है। हमारे Cargo.toml में निर्भरता को अपडेट करें:

 [dependencies] x86_64 = "0.4.0" # or later 

पृष्ठ तालिकाओं तक पहुंच

कर्नेल से पेज टेबल एक्सेस करना इतना आसान नहीं है जितना यह लग सकता है। समस्या को समझने के लिए, पिछले लेख के चार स्तरीय तालिका पदानुक्रम पर एक और नज़र डालें:



महत्वपूर्ण बात यह है कि प्रत्येक पृष्ठ प्रविष्टि अगली तालिका का भौतिक पता संग्रहीत करती है। यह इन पतों के अनुवाद से बचता है, जो प्रदर्शन को कम करता है और आसानी से अंतहीन छोरों की ओर जाता है।

समस्या यह है कि हम सीधे कर्नेल से भौतिक पतों तक नहीं पहुँच सकते हैं, क्योंकि यह वर्चुअल पतों पर भी काम करता है। उदाहरण के लिए, जब हम एड्रेस 4 KiB , तो हम वर्चुअल एड्रेस 4 KiB तक पहुंचते हैं, न कि उस भौतिक पते पर, जहां 4 वें स्तर के पेजों की तालिका संग्रहीत है। यदि हम 4 KiB के भौतिक पते तक पहुंचना चाहते हैं, तो हमें कुछ आभासी पते का उपयोग करने की आवश्यकता है, जो इसमें अनुवादित है।

इसलिए, पृष्ठ तालिकाओं के फ़्रेमों तक पहुंचने के लिए, आपको इन फ़्रेमों के लिए कुछ वर्चुअल पेजों को मैप करने की आवश्यकता है। ऐसे मैपिंग बनाने के लिए अलग-अलग तरीके हैं।

1. एक सरल समाधान सभी पृष्ठ तालिकाओं का समान प्रदर्शन है ।



इस उदाहरण में, हम फ्रेम के समान प्रदर्शन को देखते हैं। पृष्ठ तालिकाओं के भौतिक पते एक ही समय में मान्य आभासी पते हैं, जिससे हम आसानी से सभी स्तरों के पृष्ठ तालिकाओं तक पहुंच सकते हैं, जो रजिस्टर सीआर 3 से शुरू होते हैं।

हालांकि, यह दृष्टिकोण वर्चुअल एड्रेस स्पेस को अव्यवस्थित करता है और मुफ्त मेमोरी के बड़े सन्निहित क्षेत्रों को खोजना मुश्किल बनाता है। मान लीजिए कि हम उपरोक्त आकृति में 1000 KiB वर्चुअल मेमोरी क्षेत्र बनाना चाहते हैं, उदाहरण के लिए, किसी फ़ाइल को मेमोरी में प्रदर्शित करना । हम 28 KiB क्षेत्र से शुरू नहीं कर सकते, क्योंकि यह 1004 KiB पर पहले से ही मौजूद पृष्ठ पर टिकी हुई है। इसलिए, आपको तब तक आगे देखना होगा जब तक कि हम एक उपयुक्त बड़े टुकड़े को न पा लें, उदाहरण के लिए, 1008 KiB साथ। खंडित मेमोरी में उतनी ही विखंडन की समस्या है।

इसके अलावा, नए पृष्ठ तालिकाओं का निर्माण अधिक जटिल है, क्योंकि हमें उन भौतिक फ़्रेमों को खोजने की आवश्यकता है जिनके संबंधित पृष्ठ अभी तक उपयोग नहीं किए गए हैं। उदाहरण के लिए, हमारी फ़ाइल के लिए, हमने 10008 kB वर्चुअल मेमोरी का एक क्षेत्र आरक्षित किया है, जिसका पता 1008 KiB । अब हम 1000 KiB और 2008 KiB बीच भौतिक पते के साथ किसी भी फ्रेम का उपयोग नहीं कर सकते, क्योंकि इसे पहचान के रूप में प्रदर्शित नहीं किया जा सकता है।

2. एक अन्य विकल्प केवल अस्थायी रूप से पृष्ठ तालिकाओं को प्रसारित करना है जब आपको उन्हें एक्सेस करने की आवश्यकता होती है। अस्थायी तुलना के लिए, केवल प्रथम स्तर की तालिका का एक समान प्रदर्शन आवश्यक है:



इस आंकड़े में, एक स्तर 1 तालिका वर्चुअल एड्रेस स्पेस के पहले 2 MiB का प्रबंधन करती है। यह संभव है क्योंकि CR3 रजिस्टर से पहुंच 4, 3 और 2 के स्तरों में शून्य प्रविष्टियों के माध्यम से है। सूचकांक 8 के साथ रिकॉर्ड 32 KiB पर आभासी पृष्ठ को 32 KiB में एक भौतिक फ्रेम में अनुवाद करता है, जिससे स्तर 1 तालिका की पहचान होती है। आकृति में यह एक क्षैतिज तीर द्वारा दिखाया गया है।

आइडेंटली मैप्ड लेवल 1 टेबल पर लिखकर, हमारा कर्नेल 511 टाइम कंपेरिजन (पहचान मैपिंग के लिए जरूरी रिकॉर्ड माइनस 512 मिनट) तक बना सकता है। उपरोक्त उदाहरण में, कर्नेल ने 24 KiB पर एक फ्रेम के साथ एक स्तर 1 तालिका के अशक्त रिकॉर्ड का मिलान किया। इसने डॉटेड तीर द्वारा इंगित पृष्ठ 2 लेवल टेबल के भौतिक फ्रेम में 0 KiB पर वर्चुअल पेज का एक अस्थायी मानचित्रण बनाया। अब कर्नेल 0 KiB पर शुरू होने वाले पेज पर लिखकर लेवल 2 टेबल को एक्सेस कर सकता है।

इस प्रकार, अस्थायी मैपिंग के साथ पृष्ठ तालिका के एक मनमाने ढंग से फ्रेम तक पहुंच के लिए निम्नलिखित क्रियाएं शामिल हैं:

• समान रूप से प्रदर्शित स्तर 1 तालिका में एक निःशुल्क प्रविष्टि प्राप्त करें।
  
• इस प्रविष्टि को उस पृष्ठ तालिका के भौतिक फ़्रेम में मैप करें जिसे हम एक्सेस करना चाहते हैं।
  
• प्रवेश के साथ जुड़े आभासी पृष्ठ के माध्यम से इस फ्रेम तक पहुंचें।
  
• अप्रयुक्त करने के लिए वापस रिकॉर्ड सेट, जिससे अस्थायी मानचित्रण को हटाने।

इस दृष्टिकोण के साथ, आभासी पता स्थान साफ ​​रहता है, क्योंकि समान 512 आभासी पृष्ठ लगातार उपयोग किए जाते हैं। नुकसान कुछ बोझिल है, खासकर जब से एक नई तुलना में तालिका के कई स्तरों को बदलने की आवश्यकता हो सकती है, अर्थात, हमें कई बार वर्णित प्रक्रिया को दोहराने की आवश्यकता होती है।

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

पुनरावर्ती पृष्ठ सारणी

विचार अपने आप में चौथे स्तर की तालिका से कुछ रिकॉर्ड का अनुवाद करना है। इस प्रकार, हम वास्तव में वर्चुअल एड्रेस स्पेस का एक हिस्सा आरक्षित करते हैं और सभी वर्तमान और भविष्य के टेबल फ्रेम को इस स्पेस में मैप करते हैं।

आइए एक उदाहरण देखें कि यह कैसे काम करता है:



लेख की शुरुआत में उदाहरण से एकमात्र अंतर 4 टेबल के स्तर में सूचकांक 511 साथ एक अतिरिक्त रिकॉर्ड है, जिसे भौतिक फ्रेम 4 KiB में मैप किया जाता है, जो इस तालिका में ही स्थित है।

जब सीपीयू इस रिकॉर्ड पर जाता है, तो यह स्तर 3 तालिका को संदर्भित नहीं करता है, लेकिन फिर से स्तर 4 तालिका को संदर्भित करता है। यह एक पुनरावर्ती फ़ंक्शन के समान है जो स्वयं को कॉल करता है। यह महत्वपूर्ण है कि प्रोसेसर मानता है कि स्तर 4 तालिका में प्रत्येक रिकॉर्ड स्तर 3 तालिका के लिए इंगित करता है, इसलिए अब यह स्तर 4 तालिका को स्तर 3 तालिका के रूप में मानता है। यह काम करता है क्योंकि x86_64 में सभी स्तरों के तालिकाओं की संरचना समान होती है।

वास्तविक रूपांतरण शुरू करने से पहले एक या अधिक बार पुनरावर्ती रिकॉर्ड का पालन करके, हम प्रोसेसर के माध्यम से जाने वाले स्तरों की संख्या को प्रभावी ढंग से कम कर सकते हैं। उदाहरण के लिए, यदि हम एक बार पुनरावर्ती रिकॉर्ड का पालन करते हैं, और फिर स्तर 3 तालिका पर जाते हैं, तो प्रोसेसर सोचता है कि स्तर 3 तालिका एक स्तर 2 तालिका है। आगे बढ़ते हुए, वह स्तर 2 तालिका को स्तर 1 तालिका के रूप में मानता है, और स्तर तालिका को मैप किया गया है। भौतिक स्मृति में फ्रेम। इसका मतलब है कि अब हम पेज लेवल 1 टेबल पर पढ़ और लिख सकते हैं क्योंकि प्रोसेसर को लगता है कि यह मैप्ड फ्रेम है। नीचे दिया गया आंकड़ा इस अनुवाद के पाँच चरणों को दर्शाता है:



इसी तरह, हम रूपांतरण को शुरू करने से पहले दो बार पारित होने वाले स्तर को कम करने के लिए एक पुनरावर्ती प्रविष्टि का पालन कर सकते हैं:



आइए इस प्रक्रिया को चरण दर चरण देखें। सबसे पहले, CPU स्तर 4 तालिका में एक पुनरावर्ती प्रविष्टि का अनुसरण करता है और सोचता है कि यह स्तर 3 तालिका तक पहुंच गया है। फिर वह पुनरावर्ती रिकॉर्ड का पालन करता है और सोचता है कि यह स्तर 2 तक पहुंच गया है। लेकिन वास्तव में यह अभी भी 4 के स्तर पर है। तब CPU नए पते पर जाता है। और स्तर 3 तालिका में शामिल हो जाता है, लेकिन यह पहले से ही स्तर 1 तालिका में सोचता है। अंत में, स्तर 2 तालिका में अगले प्रवेश बिंदु पर, प्रोसेसर को लगता है कि उसने भौतिक मेमोरी फ्रेम तक पहुंच बनाई है। यह हमें एक स्तर 2 टेबल पर पढ़ने और लिखने की अनुमति देता है।

स्तर 3 और 4 की तालिकाएँ भी एक्सेस की गई हैं। स्तर 3 की तालिका तक पहुँचने के लिए हम तीन बार एक पुनरावर्ती रिकॉर्ड का पालन करते हैं: प्रोसेसर सोचता है कि यह पहले से ही स्तर 1 की तालिका में है, और अगले चरण में हम स्तर 3 तक पहुँचते हैं, जिसे सीपीयू एक मैप्ड फ़्रेम के रूप में देखता है। स्तर 4 तालिका को स्वयं एक्सेस करने के लिए, हम केवल चार बार पुनरावर्ती रिकॉर्ड का पालन करते हैं जब तक कि प्रोसेसर स्तर 4 तालिका को मैप किए गए फ्रेम के रूप में संसाधित नहीं करता (नीचे की आकृति में नीले रंग में)।



अवधारणा पहली बार में समझना मुश्किल है, लेकिन व्यवहार में यह बहुत अच्छी तरह से काम करता है।

पता गणना

इसलिए, हम एक या अधिक बार पुनरावर्ती रिकॉर्ड का पालन करके सभी स्तरों की तालिकाओं तक पहुँच सकते हैं। चूंकि चार स्तरों के तालिकाओं में अनुक्रमित को सीधे आभासी पते से प्राप्त किया जाता है, इसलिए इस पद्धति के लिए विशेष आभासी पते बनाए जाने चाहिए। जैसा कि हम याद करते हैं, पेज टेबल इंडेक्स इस पते से निकाले जाते हैं:



मान लीजिए कि हम एक स्तर 1 तालिका का उपयोग करना चाहते हैं जो एक विशिष्ट पृष्ठ प्रदर्शित करता है। जैसा कि हमने ऊपर सीखा है, आपको एक बार पुनरावर्ती रिकॉर्ड से गुजरना होगा, और फिर 4, 3 और 2 के स्तर के सूचकांक के माध्यम से। ऐसा करने के लिए, हम सभी एड्रेस ब्लॉक को एक ब्लॉक में दाईं ओर ले जाते हैं और पुनरावर्ती रिकॉर्ड के इंडेक्स को लेवल 4 के शुरुआती इंडेक्स के स्थान पर सेट करते हैं:



इस पृष्ठ के स्तर 2 तालिका तक पहुँचने के लिए, हम सभी सूचकांक खंडों को दो खंडों को दाईं ओर ले जाते हैं और पुनरावर्ती सूचकांक को दोनों स्रोत ब्लॉकों के स्तर पर सेट करते हैं: स्तर 4 और स्तर 3:



स्तर 3 तालिका तक पहुंचने के लिए, हम ऐसा ही करते हैं, हम अभी पहले से ही तीन पते वाले ब्लॉक पर जाते हैं।



अंत में, स्तर 4 तालिका तक पहुंचने के लिए, चार ब्लॉकों को दाईं ओर ले जाएं।



अब आप सभी चार स्तरों के पृष्ठ तालिकाओं के लिए आभासी पतों की गणना कर सकते हैं। हम एक पते की भी गणना कर सकते हैं, जो एक विशिष्ट पृष्ठ तालिका प्रविष्टि को इंगित करता है, इसके सूचकांक को 8 से गुणा करके, पृष्ठ तालिका प्रविष्टि का आकार।

नीचे दी गई तालिका विभिन्न प्रकार के फ़्रेमों तक पहुंचने के लिए पते की संरचना को दर्शाती है:

के लिए वर्चुअल एड्रेस	पता संरचना ( अष्टाधारी )
पेज	0o_SSSSSS_AAA_BBB_CCC_DDD_EEEE
स्तर 1 तालिका में प्रवेश	0o_SSSSSS_RRR_AAA_BBB_CCC_DDDD
एक स्तर 2 तालिका में प्रवेश	0o_SSSSSS_RRR_RRR_AAA_BBB_CCCC
एक स्तर 3 तालिका में प्रवेश	0o_SSSSSS_RRR_RRR_RRR_AAA_BBBB
स्तर 4 तालिका में प्रवेश	0o_SSSSSS_RRR_RRR_RRR_RRR_AAAA

यहां स्तर 4 सूचकांक है, स्तर 3 है, स्तर 2 है, और DDD प्रदर्शित फ्रेम के लिए स्तर 1 सूचकांक है, EEEE इसकी भरपाई है। RRR पुनरावर्ती रिकॉर्ड का सूचकांक है। एक सूचकांक (तीन अंक) 8 (पेज टेबल प्रविष्टि के आकार) से गुणा करके एक ऑफसेट (चार अंक) में बदल जाता है। इस ऑफसेट के साथ, परिणामी पता सीधे संबंधित तालिका तालिका प्रविष्टि को इंगित करता है।

SSSS हस्ताक्षरित अंक के विस्तार बिट्स हैं, SSSS , वे सभी बिट 47 की प्रतियां हैं। यह x86_64 वास्तुकला में मान्य पते के लिए एक विशेष आवश्यकता है, जिसकी हमने पिछले लेख में चर्चा की थी।

पते ऑक्टल हैं , क्योंकि प्रत्येक ऑक्टल चरित्र तीन बिट्स का प्रतिनिधित्व करता है, जो आपको अलग-अलग स्तरों पर 9-बिट इंडेक्स टेबल को स्पष्ट रूप से अलग करने की अनुमति देता है। यह हेक्साडेसिमल प्रणाली में संभव नहीं है, जहां प्रत्येक चरित्र चार बिट्स का प्रतिनिधित्व करता है।

कार्यान्वयन

इस सभी सिद्धांत के बाद, हम आखिरकार कार्यान्वयन के साथ आगे बढ़ सकते हैं। आसानी से, लोडर न केवल पेज टेबल उत्पन्न करता है, बल्कि स्तर 4 तालिका के अंतिम रिकॉर्ड में भी एक पुनरावर्ती प्रदर्शन होता है। लोडर ने ऐसा इसलिए किया क्योंकि अन्यथा चिकन या अंडे की समस्या होगी: हमें पुनरावर्ती नक्शा बनाने के लिए स्तर 4 तालिका तक पहुंचने की आवश्यकता है। लेकिन हम इसे किसी भी प्रदर्शन के बिना उपयोग नहीं कर सकते।

हमने पहले ही इस पुनरावर्ती मैपिंग का उपयोग पिछले लेख के अंत में हार्ड-कोडित पते 0xffff_ffff_ffff_f000 माध्यम से स्तर 4 तालिका तक पहुंचने के लिए किया था। यदि हम इस पते को ऑक्टल में परिवर्तित करते हैं और ऊपर दी गई तालिका से इसकी तुलना करते हैं, तो हम देखेंगे कि यह RRR = 0o777 , AAAA = 0 और साइन 1 के विस्तार बिट्स के साथ स्तर 4 तालिका में रिकॉर्ड की संरचना से मेल खाती है:

  संरचना: 0o_SSSSSS_RRR_RRR_RRR_RRR_AAAA
 पता: 0o_177777_777_777_777_777_0000 

पुनरावर्ती तालिकाओं के ज्ञान के लिए धन्यवाद, अब हम सभी सक्रिय तालिकाओं तक पहुंचने के लिए आभासी पते बना सकते हैं। और प्रसारण समारोह बनाते हैं।

पता अनुवाद

पहले चरण के रूप में, एक फ़ंक्शन बनाएं जो एक वर्चुअल एड्रेस को एक भौतिक पते में परिवर्तित करता है, पेज टेबल के पदानुक्रम से गुजर रहा है:

 // in src/lib.rs pub mod memory; 

 // in src/memory.rs use x86_64::PhysAddr; use x86_64::structures::paging::PageTable; /// Returns the physical address for the given virtual address, or `None` if the /// virtual address is not mapped. pub fn translate_addr(addr: usize) -> Option<PhysAddr> { // introduce variables for the recursive index and the sign extension bits // TODO: Don't hardcode these values let r = 0o777; // recursive index let sign = 0o177777 << 48; // sign extension // retrieve the page table indices of the address that we want to translate let l4_idx = (addr >> 39) & 0o777; // level 4 index let l3_idx = (addr >> 30) & 0o777; // level 3 index let l2_idx = (addr >> 21) & 0o777; // level 2 index let l1_idx = (addr >> 12) & 0o777; // level 1 index let page_offset = addr & 0o7777; // calculate the table addresses let level_4_table_addr = sign | (r << 39) | (r << 30) | (r << 21) | (r << 12); let level_3_table_addr = sign | (r << 39) | (r << 30) | (r << 21) | (l4_idx << 12); let level_2_table_addr = sign | (r << 39) | (r << 30) | (l4_idx << 21) | (l3_idx << 12); let level_1_table_addr = sign | (r << 39) | (l4_idx << 30) | (l3_idx << 21) | (l2_idx << 12); // check that level 4 entry is mapped let level_4_table = unsafe { &*(level_4_table_addr as *const PageTable) }; if level_4_table[l4_idx].addr().is_null() { return None; } // check that level 3 entry is mapped let level_3_table = unsafe { &*(level_3_table_addr as *const PageTable) }; if level_3_table[l3_idx].addr().is_null() { return None; } // check that level 2 entry is mapped let level_2_table = unsafe { &*(level_2_table_addr as *const PageTable) }; if level_2_table[l2_idx].addr().is_null() { return None; } // check that level 1 entry is mapped and retrieve physical address from it let level_1_table = unsafe { &*(level_1_table_addr as *const PageTable) }; let phys_addr = level_1_table[l1_idx].addr(); if phys_addr.is_null() { return None; } Some(phys_addr + page_offset) } 

सबसे पहले, हम पुनरावर्ती सूचकांक (511 = 0o777 ) और संकेत विस्तार बिट्स के लिए चर पेश करते हैं (प्रत्येक 1 है)। तब हम पृष्ठ सारणी के अनुक्रमित और बिटवाइज संचालन के माध्यम से ऑफसेट की गणना करते हैं, जैसा कि चित्रण में दिखाया गया है:



अगला चरण चार पृष्ठ तालिकाओं के आभासी पतों की गणना करना है, जैसा कि पिछले भाग में बताया गया है। अगला, फ़ंक्शन में, हम इनमें से प्रत्येक पते को PageTable लिंक में परिवर्तित करते हैं। ये असुरक्षित ऑपरेशन हैं क्योंकि कंपाइलर को पता नहीं चल सकता है कि ये पते वैध हैं।

पते की गणना करने के बाद, हम इंडेक्सिंग ऑपरेटर का उपयोग रिकॉर्ड 4 तालिका के स्तर को देखने के लिए करते हैं। यदि यह रिकॉर्ड शून्य है, तो इस स्तर 4 रिकॉर्ड के लिए कोई स्तर 3 तालिका नहीं है। इसका मतलब यह है कि addr किसी भी भौतिक मेमोरी में मैप नहीं किया गया है। इसलिए हम None लौटाते। अन्यथा, हम जानते हैं कि एक स्तर 3 तालिका मौजूद है। फिर हम प्रक्रिया को दोहराते हैं, जैसा कि पिछले स्तर पर है।

उच्च स्तर के तीन पृष्ठों की जांच करने के बाद, हम अंत में स्तर 1 तालिका के रिकॉर्ड को पढ़ सकते हैं, जो हमें भौतिक फ्रेम बताता है जिसके साथ पता मैप किया गया है। अंतिम चरण के रूप में, पृष्ठ ऑफसेट को इसमें जोड़ें - और पता वापस करें।

अगर हमें पता था कि पता मैप किया गया था, तो हम उच्च स्तर के पृष्ठों को देखे बिना सीधे स्तर 1 तालिका तक पहुंच सकते हैं। लेकिन जब से हम यह नहीं जानते हैं, हमें पहले यह जांचने की आवश्यकता है कि क्या कोई स्तर 1 तालिका मौजूद है, अन्यथा हमारा कार्य बेजोड़ पतों के लिए एक पृष्ठ अनुपलब्ध त्रुटि वापस करेगा।

कोशिश

आइए हमारे _start फ़ंक्शन में वर्चुअल पतों के लिए अनुवाद फ़ंक्शन का उपयोग करने का प्रयास करें:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory::translate_addr; // the identity-mapped vga buffer page println!("0xb8000 -> {:?}", translate_addr(0xb8000)); // some code page println!("0x20010a -> {:?}", translate_addr(0x20010a)); // some stack page println!("0x57ac001ffe48 -> {:?}", translate_addr(0x57ac001ffe48)); println!("It did not crash!"); blog_os::hlt_loop(); } 

शुरू करने के बाद, हम निम्नलिखित परिणाम देखते हैं:



जैसा कि अपेक्षित था, पहचानकर्ता के साथ जुड़ा हुआ 0xb8000 का पता उसी भौतिक पते पर अनुवाद करता है। कोड पृष्ठ और स्टैक पृष्ठ कुछ मनमाने भौतिक पते में परिवर्तित हो जाते हैं, जो इस बात पर निर्भर करते हैं कि लोडर ने हमारी कर्नेल के लिए प्रारंभिक मानचित्रण कैसे बनाया।

RecursivePageTable

x86_64 एक RecursivePageTable प्रकार प्रदान करता है जो विभिन्न पृष्ठ तालिका संचालन के लिए सुरक्षित सार लागू करता है। इस प्रकार का उपयोग करते हुए, आप translate_addr फ़ंक्शन को अधिक संक्षिप्त रूप से कार्यान्वित कर सकते हैं:

 // in src/memory.rs use x86_64::structures::paging::{Mapper, Page, PageTable, RecursivePageTable}; use x86_64::{VirtAddr, PhysAddr}; /// Creates a RecursivePageTable instance from the level 4 address. /// /// This function is unsafe because it can break memory safety if an invalid /// address is passed. pub unsafe fn init(level_4_table_addr: usize) -> RecursivePageTable<'static> { let level_4_table_ptr = level_4_table_addr as *mut PageTable; let level_4_table = &mut *level_4_table_ptr; RecursivePageTable::new(level_4_table).unwrap() } /// Returns the physical address for the given virtual address, or `None` if /// the virtual address is not mapped. pub fn translate_addr(addr: u64, recursive_page_table: &RecursivePageTable) -> Option<PhysAddr> { let addr = VirtAddr::new(addr); let page: Page = Page::containing_address(addr); // perform the translation let frame = recursive_page_table.translate_page(page); frame.map(|frame| frame.start_address() + u64::from(addr.page_offset())) } 

RecursivePageTable प्रकार पूरी तरह से पेज टेबल के असुरक्षित क्रॉल को एनकैप्सुलेट करता है, इसलिए translate_addr फ़ंक्शन में unsafe कोड की अब आवश्यकता नहीं है। पारित level_4_table_addr की शुद्धता की गारंटी के लिए level_4_table_addr फ़ंक्शन असुरक्षित है।

हमारे _start फ़ंक्शन को फ़ंक्शन को पुन: साइन इन करने के लिए अपडेट किया जाना चाहिए:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory::{self, translate_addr}; const LEVEL_4_TABLE_ADDR: usize = 0o_177777_777_777_777_777_0000; let recursive_page_table = unsafe { memory::init(LEVEL_4_TABLE_ADDR) }; // the identity-mapped vga buffer page println!("0xb8000 -> {:?}", translate_addr(0xb8000, &recursive_page_table)); // some code page println!("0x20010a -> {:?}", translate_addr(0x20010a, &recursive_page_table)); // some stack page println!("0x57ac001ffe48 -> {:?}", translate_addr(0x57ac001ffe48, &recursive_page_table)); println!("It did not crash!"); blog_os::hlt_loop(); } 

अब, LEVEL_4_TABLE_ADDR को LEVEL_4_TABLE_ADDR में पास करने और असुरक्षित कच्चे पॉइंटर्स के माध्यम से पेज टेबल तक पहुंचने के बजाय, हम RecursivePageTable प्रकार के संदर्भ पास करते हैं। इस प्रकार, अब हमारे पास एक सुरक्षित अमूर्त और स्वामित्व का एक स्पष्ट शब्दार्थ है। यह सुनिश्चित करता है कि हम गलती से साझा पहुंच में पेज टेबल को बदल नहीं सकते, क्योंकि इसे बदलने के लिए RecursivePageTable के अनन्य कब्जे की आवश्यकता होती है।

यह फ़ंक्शन मैन्युअल रूप से लिखित मूल अनुवाद फ़ंक्शन के समान परिणाम देता है।

असुरक्षित सुविधाओं को सुरक्षित बनाना

memory::initएक असुरक्षित कार्य है: इसे कॉल करने के लिए एक ब्लॉक की आवश्यकता होती है unsafe, क्योंकि कॉल करने वाले को यह गारंटी देनी चाहिए कि कुछ आवश्यकताओं को पूरा किया गया है। हमारे मामले में, आवश्यकता यह है कि प्रेषित पता ठीक से स्तर 4 पृष्ठ तालिका के भौतिक फ्रेम पर मैप किया गया है। असुरक्षित फ़ंक्शन के पूरे शरीर

को ब्लॉक में unsafeरखा गया है, ताकि अतिरिक्त ब्लॉक बनाए बिना सभी प्रकार के ऑपरेशन किए जा सकें unsafe। इसलिए, हमें डेरेफ़रिंग के लिए असुरक्षित ब्लॉक की आवश्यकता नहीं है level_4_table_ptr:

 pub unsafe fn init(level_4_table_addr: usize) -> RecursivePageTable<'static> { let level_4_table_ptr = level_4_table_addr as *mut PageTable; let level_4_table = &mut *level_4_table_ptr; // <- this operation is unsafe RecursivePageTable::new(level_4_table).unwrap() } 

समस्या यह है कि हम तुरंत यह नहीं देखते हैं कि कौन से हिस्से असुरक्षित हैं। उदाहरण के लिए, किसी फ़ंक्शन की परिभाषा को देखे बिना ,RecursivePageTable::new हम यह नहीं कह सकते कि यह सुरक्षित है या नहीं। इसलिए गलती से कुछ असुरक्षित कोड छोड़ना बहुत आसान है।

इस समस्या से बचने के लिए, आप एक सुरक्षित अंतर्निहित फ़ंक्शन जोड़ सकते हैं:

 // in src/memory.rs pub unsafe fn init(level_4_table_addr: usize) -> RecursivePageTable<'static> { /// Rust currently treats the whole body of unsafe functions as an unsafe /// block, which makes it difficult to see which operations are unsafe. To /// limit the scope of unsafe we use a safe inner function. fn init_inner(level_4_table_addr: usize) -> RecursivePageTable<'static> { let level_4_table_ptr = level_4_table_addr as *mut PageTable; let level_4_table = unsafe { &mut *level_4_table_ptr }; RecursivePageTable::new(level_4_table).unwrap() } init_inner(level_4_table_addr) } 

अब unsafeडेरेफेरिंग के लिए ब्लॉक को फिर से आवश्यक है level_4_table_ptr, और हम तुरंत देखते हैं कि ये केवल असुरक्षित ऑपरेशन हैं। असुरक्षित वर्तमान में असुरक्षित कार्यों की इस असफल संपत्ति को बदलने के लिए RFC खुला है।

एक नई मैपिंग बनाएं

जब हम पेज टेबल पढ़ते हैं और रूपांतरण फ़ंक्शन बनाते हैं, तो अगला चरण पेज टेबल पदानुक्रम में एक नया मैपिंग बनाना होता है।

इस ऑपरेशन की जटिलता उस आभासी पृष्ठ पर निर्भर करती है जिसे हम प्रदर्शित करना चाहते हैं। सरलतम स्थिति में, इस पृष्ठ के लिए पहले से ही 1 पृष्ठों की एक तालिका मौजूद है, और हमें केवल एक प्रविष्टि करनी है। सबसे कठिन मामले में, पृष्ठ स्मृति क्षेत्र में है जिसके लिए स्तर 3 अभी तक मौजूद नहीं है, इसलिए पहले आपको स्तर 3, स्तर 2 और स्तर 1 की नई तालिकाएं बनाने की आवश्यकता है।

आइए एक साधारण मामले से शुरू करें जब आपको नई तालिकाएँ बनाने की आवश्यकता न हो। लोडर को आभासी पता स्थान के पहले मेगाबाइट में लोड किया जाता है, इसलिए हम जानते हैं कि इस क्षेत्र के लिए एक मान्य स्तर 1 तालिका है। हमारे उदाहरण के लिए, हम इस स्मृति क्षेत्र में किसी भी अप्रयुक्त पृष्ठ का चयन कर सकते हैं, उदाहरण के लिए, पते पर पृष्ठ 0x1000। हम वांछित फ्रेम के रूप में 0xb8000वीजीए टेक्स्ट बफर के फ्रेम का उपयोग करते हैं । यह जांचना बहुत आसान है कि हमारा पता अनुवाद कैसे काम करता है।

हम इसे create_mapingमॉड्यूल में एक नए फ़ंक्शन में कार्यान्वित करते हैं memory:

 // in src/memory.rs use x86_64::structures::paging::{FrameAllocator, PhysFrame, Size4KiB}; pub fn create_example_mapping( recursive_page_table: &mut RecursivePageTable, frame_allocator: &mut impl FrameAllocator<Size4KiB>, ) { use x86_64::structures::paging::PageTableFlags as Flags; let page: Page = Page::containing_address(VirtAddr::new(0x1000)); let frame = PhysFrame::containing_address(PhysAddr::new(0xb8000)); let flags = Flags::PRESENT | Flags::WRITABLE; let map_to_result = unsafe { recursive_page_table.map_to(page, frame, flags, frame_allocator) }; map_to_result.expect("map_to failed").flush(); } 

फ़ंक्शन एक परस्पर संदर्भ को स्वीकार करता है RecursivePageTable(यह इसे बदल देगा) और FrameAllocator, जिसे नीचे समझाया गया है। फिर यह पते पर भौतिक फ्रेम के साथ पृष्ठ पर नक्शा बनाने के लिए map_toट्रे में फ़ंक्शन को लागू करता है । फ़ंक्शन सुरक्षित नहीं है, क्योंकि अमान्य तर्कों के साथ मेमोरी सुरक्षा का उल्लंघन करना संभव है। तर्कों के अलावा और , फ़ंक्शन दो और तर्क लेता है। तीसरा तर्क पृष्ठ तालिका के लिए झंडे का सेट है। हम सभी वैध प्रविष्टियों के लिए आवश्यक ध्वज और लेखन क्षमता के लिए ध्वज निर्धारित करते हैं। चौथा तर्क कुछ संरचना होना चाहिए जो विशेषता को लागू करता है । यह तर्क विधि द्वारा आवश्यक है।Mapper0x10000xb8000

pageframemap_toPRESENTWRITABLE

FrameAllocatormap_toक्योंकि नए पेज टेबल बनाने के लिए अप्रयुक्त फ्रेम की आवश्यकता हो सकती है। कार्यान्वयन तर्क विशेषता की आवश्यकता है Size4KiBप्रकार के रूप में, Pageऔर PhysFrameकर रहे हैं सार्वभौमिक विशेषता के लिए PageSize, मानक 4 KiB पृष्ठों के साथ और भारी पृष्ठों 2 MiB / 1 GiB साथ काम करना।

फ़ंक्शन map_toविफल हो सकता है, इसलिए यह वापस आ जाता है Result। चूंकि यह कोड का एक उदाहरण है जो विश्वसनीय नहीं होना चाहिए, हम बस expectत्रुटि होने पर घबराहट के साथ इसका उपयोग करते हैं । सफल होने पर, फ़ंक्शन एक प्रकार देता है MapperFlushजो साहचर्य अनुवाद बफर (TLB) विधि से हाल ही में मिलान किए गए पृष्ठ को साफ़ करने का एक आसान तरीका प्रदान करता है flush। जैसाResult, #[must_use]यदि हम गलती से इसे लागू करना भूल जाते हैं तो टाइप एट्रिब्यूट का उपयोग करता है और चेतावनी जारी करता है।

चूंकि हम जानते हैं कि पते 0x1000को नए पेज टेबल की आवश्यकता नहीं है, यह FrameAllocatorहमेशा वापस आ सकता है None। फ़ंक्शन का परीक्षण करने के लिए, इसे बनाएं EmptyFrameAllocator:

 // in src/memory.rs /// A FrameAllocator that always returns `None`. pub struct EmptyFrameAllocator; impl FrameAllocator<Size4KiB> for EmptyFrameAllocator { fn allocate_frame(&mut self) -> Option<PhysFrame> { None } } 

(यदि त्रुटि 'विधि allocate_frameविशेषता का सदस्य नहीं है FrameAllocator' दिखाई देती है , तो आपको x86_64संस्करण 0.4.0 में अपग्रेड करने की आवश्यकता है ।)

अब हम नए अनुवाद फ़ंक्शन का परीक्षण कर सकते हैं:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory::{create_example_mapping, EmptyFrameAllocator}; const LEVEL_4_TABLE_ADDR: usize = 0o_177777_777_777_777_777_0000; let mut recursive_page_table = unsafe { memory::init(LEVEL_4_TABLE_ADDR) }; create_example_mapping(&mut recursive_page_table, &mut EmptyFrameAllocator); unsafe { (0x1900 as *mut u64).write_volatile(0xf021f077f065f04e)}; println!("It did not crash!"); blog_os::hlt_loop(); } 

सबसे पहले, हम पते पर पृष्ठ के लिए एक मानचित्रण बनाते हैं , उदाहरण के लिए एक परस्पर लिंक के साथ 0x1000फ़ंक्शन create_example_mappingको कॉल करते हैं RecursivePageTable। यह पृष्ठ 0x1000को वीजीए टेक्स्ट बफर में बदल देता है, इसलिए हम स्क्रीन पर कुछ परिणाम देखेंगे।

फिर हम इस पृष्ठ में एक मूल्य लिखते हैं 0xf021f077f065f04e, जो "नई!" एक सफेद पृष्ठभूमि पर। बस इस मान को तुरंत पृष्ठ के शीर्ष पर लिखने की आवश्यकता नहीं है 0x1000, क्योंकि शीर्ष पंक्ति स्क्रीन से आगे बढ़ेगी println, और इसे एक ऑफसेट पर लिखें 0x900जो लगभग स्क्रीन के मध्य में स्थित है। जैसा कि हम लेख "वीजीए टेक्स्ट मोड" से जानते हैं , वीजीए बफर को लिखना अस्थिर होना चाहिए, इसलिए हम विधि का उपयोग करते हैं write_volatile।

जब हम इसे QEMU में चलाते हैं, तो हम इसे देखते हैं:



स्क्रीन पर शिलालेख।

कोड ने काम किया क्योंकि पृष्ठ प्रदर्शित करने के लिए पहले से ही एक स्तर 1 तालिका थी 0x1000। यदि हम ऐसे पृष्ठ का अनुवाद करने का प्रयास करते हैं जिसके लिए ऐसी तालिका अभी तक मौजूद नहीं है, तो फ़ंक्शन map_toएक त्रुटि लौटाएगा, क्योंकि यह नए पृष्ठ तालिकाओं को बनाने के लिए फ़्रेमों का चयन करने का प्रयास करेगा EmptyFrameAllocator। यदि हम 0xdeadbeaf000इसके बजाय पृष्ठ का अनुवाद करने का प्रयास करते हैं, तो हम इसे देखेंगे 0x1000:

 // in src/memory.rs pub fn create_example_mapping(…) { […] let page: Page = Page::containing_address(VirtAddr::new(0xdeadbeaf000)); […] } // in src/main.rs #[no_mangle] pub extern "C" fn _start() -> ! { […] unsafe { (0xdeadbeaf900 as *mut u64).write_volatile(0xf021f077f065f04e)}; […] } 

प्रारंभ करते समय, निम्न त्रुटि संदेश के साथ एक घबराहट शुरू होती है:

 'map_to में विफल: फ़्रेमअलोकेशन फ़ेल्ड', /.../result.rs:999pes 

उन पृष्ठों को प्रदर्शित करने के लिए जिनके पास अभी तक पृष्ठ स्तर 1 तालिका नहीं है, आपको सही एक बनाने की आवश्यकता है FrameAllocator। लेकिन आप कैसे जानते हैं कि कौन से फ्रेम मुफ्त हैं और कितनी भौतिक मेमोरी उपलब्ध है?

बूट जानकारी

विभिन्न कंप्यूटरों में विभिन्न प्रकार की भौतिक मेमोरी होती है और विभिन्न क्षेत्रों जैसे VGA भिन्न उपकरणों द्वारा आरक्षित होती हैं। केवल BIOS या यूईएफआई फर्मवेयर को पता है कि कौन से मेमोरी क्षेत्र का उपयोग किया जा सकता है और कौन से आरक्षित हैं। दोनों फर्मवेयर मानक मेमोरी आवंटन कार्ड प्राप्त करने के लिए कार्य प्रदान करते हैं, लेकिन उन्हें केवल डाउनलोड की शुरुआत में ही बुलाया जा सकता है। इसलिए, हमारे बूटलोडर ने पहले से ही (और अन्य) BIOS से जानकारी का अनुरोध किया है।

ओएस के कर्नेल को जानकारी पास करने के लिए, फ़ंक्शन _startको कॉल करते समय एक तर्क के रूप में लोडर बूट की सूचना संरचना का लिंक देता है। इस तर्क को हमारे कार्य में जोड़ें:

 // in src/main.rs use bootloader::bootinfo::BootInfo; #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start(boot_info: &'static BootInfo) -> ! { // new argument […] } 

संरचना को BootInfoअभी भी अंतिम रूप दिया जा रहा है, इसलिए बूस्ट लोडर के भविष्य के संस्करणों पर अपग्रेड करते समय क्रैश होने पर आश्चर्य न करें जो कि सेमर के अनुकूल नहीं हैं । उनके पास वर्तमान में तीन क्षेत्र हैं p4_table_addr, memory_mapऔर package:

• फ़ील्ड p4_table_addrमें स्तर 4 पृष्ठों की तालिका का एक पुनरावर्ती वर्चुअल पता होता है। इसके लिए धन्यवाद, पते को मुश्किल से पंजीकृत करना आवश्यक नहीं है 0o_177777_777_777_777_777_0000।
  
• क्षेत्र memory_mapसबसे अधिक रुचि का है, क्योंकि इसमें सभी मेमोरी क्षेत्रों और उनके प्रकार (अप्रयुक्त, आरक्षित या अन्य) की एक सूची शामिल है।
  
• फ़ील्ड packageलोडर के साथ अतिरिक्त डेटा को जोड़ने के लिए वर्तमान फ़ंक्शन है। कार्यान्वयन पूरा नहीं हुआ है, इसलिए हम इसे अभी के लिए अनदेखा कर सकते हैं।

memory_mapसही बनाने के लिए फ़ील्ड का उपयोग करने से पहले FrameAllocator, हम सही प्रकार के तर्क की गारंटी देना चाहते हैं boot_info।

मैक्रो entry_point

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

हस्ताक्षर को सत्यापित करने के लिए, bootloaderप्रवेश बिंदु के रूप में रस्ट फ़ंक्शन को परिभाषित करने के लिए टोकरा, entry_pointमान्य प्रकारों के साथ एक मैक्रो का उपयोग करता है । हम इस मैक्रो के लिए अपने कार्य को फिर से लिखते हैं:

 // in src/main.rs use bootloader::{bootinfo::BootInfo, entry_point}; entry_point!(kernel_main); #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS let mut recursive_page_table = unsafe { memory::init(boot_info.p4_table_addr as usize) }; […] // create and test example mapping println!("It did not crash!"); blog_os::hlt_loop(); } 

प्रवेश बिंदु के लिए, आपको अब उपयोग करने की आवश्यकता नहीं है extern "C"या no_mangle, चूंकि मैक्रो वास्तविक निम्न-स्तरीय प्रविष्टि बिंदु सेट करता है _start। फ़ंक्शन kernel_mainअब पूरी तरह से सामान्य रस्ट फ़ंक्शन बन गया है, इसलिए हम इसके लिए एक मनमाना नाम चुन सकते हैं। यह महत्वपूर्ण है कि यह पहले से ही टाइप किया गया है, ताकि एक संकलन त्रुटि तब होती है जब आप फ़ंक्शन के हस्ताक्षर को बदलते हैं, उदाहरण के लिए, एक तर्क जोड़कर या उसके प्रकार को बदलकर।

ध्यान दें कि अब हम एक memory::initहार्ड-कोडेड पते पर भेज रहे हैं , लेकिन boot_info.p4_table_addr। इस प्रकार, कोड काम करेगा भले ही बूटलोडर का भविष्य संस्करण पुनरावर्ती प्रदर्शन के लिए पृष्ठ स्तर 4 तालिका तालिका में एक और प्रविष्टि का चयन करता है।

फ्रेम चयन

अब, BIOS से जानकारी के लिए धन्यवाद, हमारे पास मेमोरी आवंटन कार्ड तक पहुंच है, ताकि आप एक सामान्य फ्रेम वितरक बना सकें। आइए सामान्य कंकाल के साथ शुरू करें:

 // in src/memory.rs pub struct BootInfoFrameAllocator<I> where I: Iterator<Item = PhysFrame> { frames: I, } impl<I> FrameAllocator<Size4KiB> for BootInfoFrameAllocator<I> where I: Iterator<Item = PhysFrame> { fn allocate_frame(&mut self) -> Option<PhysFrame> { self.frames.next() } } 

क्षेत्र को framesएक मनमाना फ्रेम पुनरावृत्ति द्वारा आरंभ किया जाता है । यह आपको Iteratoralloc को कॉल करने की अनुमति देता है :: अगली विधि ।

प्रारंभिक BootInfoFrameAllocatorकार्य एक नए समारोह में होता है init_frame_allocator:

 // in src/memory.rs use bootloader::bootinfo::{MemoryMap, MemoryRegionType}; /// Create a FrameAllocator from the passed memory map pub fn init_frame_allocator( memory_map: &'static MemoryMap, ) -> BootInfoFrameAllocator<impl Iterator<Item = PhysFrame>> { // get usable regions from memory map let regions = memory_map .iter() .filter(|r| r.region_type == MemoryRegionType::Usable); // map each region to its address range let addr_ranges = regions.map(|r| r.range.start_addr()..r.range.end_addr()); // transform to an iterator of frame start addresses let frame_addresses = addr_ranges.flat_map(|r| r.into_iter().step_by(4096)); // create `PhysFrame` types from the start addresses let frames = frame_addresses.map(|addr| { PhysFrame::containing_address(PhysAddr::new(addr)) }); BootInfoFrameAllocator { frames } } 

यह फ़ंक्शन, एक कॉम्बिनेटर का उपयोग करते हुए, मूल मेमोरी आवंटन मानचित्र को उपयोग किए गए भौतिक फ़्रेमों के पुनरावृत्ति में रूपांतरित करता है:

• iter MemoryRegion . filter , . , , (, ) , InUse . , , - .
  
• map range Rust .
  
• तीसरा चरण सबसे कठिन है: हम प्रत्येक श्रेणी को विधि का उपयोग करके into_iterएक पुनरावृत्त में परिवर्तित करते हैं , और फिर प्रत्येक 4096 वें पते के साथ चयन करते हैं step_by। चूंकि पृष्ठ का आकार 4096 बाइट्स (4 KiB) है, इसलिए हमें प्रत्येक फ्रेम की शुरुआत का पता मिलता है। लोडर पृष्ठ सभी उपयोग किए गए मेमोरी क्षेत्रों को संरेखित करता है, इसलिए हमें एक संरेखण या गोलाई कोड की आवश्यकता नहीं है। के mapसाथ प्रतिस्थापित flat_map, हम Iterator<Item = u64>इसके बजाय मिलता है Iterator<Item = Iterator<Item = u64>>।
  
• अंतिम चरण में, हम PhysFrameआवश्यक पते के निर्माण के लिए शुरुआती पते को टाइप में बदल देंगे Iterator<Item = PhysFrame>। फिर नया बनाने और वापस करने के लिए इस पुनरावृत्ति का उपयोग करें BootInfoFrameAllocator।

अब हम अपने फ़ंक्शन को बदल सकते हैं kernel_mainताकि वह इसके BootInfoFrameAllocatorबजाय उदाहरण को पार करे EmptyFrameAllocator:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS use x86_64::structures::paging::{PageTable, RecursivePageTable}; let mut recursive_page_table = unsafe { memory::init(boot_info.p4_table_addr as usize) }; // new let mut frame_allocator = memory::init_frame_allocator(&boot_info.memory_map); blog_os::memory::create_mapping(&mut recursive_page_table, &mut frame_allocator); unsafe { (0xdeadbeaf900 as *mut u64).write_volatile(0xf021f077f065f04e)}; println!("It did not crash!"); blog_os::hlt_loop(); } 

अब पता अनुवाद सफल है - और हम फिर से स्क्रीन पर "नया" ब्लैक एंड व्हाइट संदेश देखते हैं ।दृश्यों के पीछे, विधि map_toअनुपलब्ध पेज टेबल बनाती है:

• से अप्रयुक्त फ्रेम निकालता है frame_allocator।
  
• इस फ्रेम के साथ एक शीर्ष-स्तरीय तालिका प्रविष्टि से मेल खाता है। फ्रेम अब एक पुनरावर्ती पृष्ठ तालिका के माध्यम से सुलभ है।
  
• एक नया, खाली पृष्ठ तालिका बनाने के लिए फ़्रेम को ज़ीरो करता है।
  
• अगले स्तर की मेज पर जाता है।

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

सारांश

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

हमने देखा कि नए मैपिंग बनाने के लिए नए टेबल के लिए अप्रयुक्त फ्रेम की आवश्यकता होती है। इस तरह के एक फ्रेम वितरक को BIOS से जानकारी के आधार पर लागू किया जा सकता है जो कि बूटलोडर हमारे कर्नेल के पास जाता है।

आगे क्या है

अगले लेख में, हम अपने कर्नेल के लिए एक ढेर स्मृति क्षेत्र बनाएंगे, जो हमें मेमोरी आवंटित करने और विभिन्न प्रकार के संग्रह का उपयोग करने की अनुमति देगा ।