एक बाधा के बाद प्रोसेसर कर्नेल कोड कैसे खोजता है?


13

जब कोई व्यवधान उत्पन्न होता है, तो प्रोसेसर वर्तमान प्रक्रिया को रोक देता है और रुकावट को संभालने के लिए कर्नेल कोड को कॉल करता है। प्रोसेसर को कैसे पता चलता है कि कर्नेल कहाँ दर्ज करना है?

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

जवाबों:


13

स्टार्टअप पर, कर्नेल एक इंटरप्ट वेक्टर टेबल (जिसे x86 पर इंटरप्ट डिस्क्रिप्टर टेबल या IDT कहा जाता है) को इनिशियलाइज़ करेगा जो प्रत्येक लाइन के लिए एक इंटरप्ट हैंडलर की ओर इशारा करता है।

80286 से पहले, आईडीटी हमेशा एक निश्चित पते पर संग्रहीत किया जाता था; 80286 से शुरू होकर, IDT को LIDTनिर्देश का उपयोग करके लोड किया गया है ।

इंटरप्ट वेक्टर टेबल एक सिंगल हैंडलर प्रति इंटरप्ट लाइन की ओर इशारा करती हैं; कहा जा रहा है, एक कर्नेल चुन सकता है, उदाहरण के लिए, एक बाधा हैंडलर प्रदान करें जो कई अन्य रुकावट दिनचर्या चलाता है, या एक एकल हैंडलर प्रदान करता है जो कुछ या सभी व्यवधानों को कवर करता है। लिनक्स इन चीजों को एक जेनेरिक इंटरप्ट हैंडलर प्रदान करके करता है जो यह निर्धारित करता है कि किस इंटरप्ट लाइन को कॉल किया गया था और कॉल करने के लिए उपयुक्त डाउनस्ट्रीम हैंडलर को खोजता है।


1
इसलिए प्रोसेसर आईडीटी को इंडेक्स के रूप में इंटरप्ट लाइन का उपयोग करता है, पीसी में प्रविष्टि डालता है और निष्पादित करना शुरू करता है? लेकिन क्या कोई सामान्य कार्य नहीं है जो सभी बाधित हैंडलर से पहले चलता है ? linux के लिए यह do_IRQ () होगा। क्या यह वह फ़ंक्शन है जो हर IDT प्रविष्टि को इंगित करता है, कोई फर्क नहीं पड़ता है?
फिलिप मुरी

@PhilippMurry हाँ। कर्नेल तब अपने स्वयं के इंटरप्ट हैंडलर के सेट का उपयोग करता है (जिनमें से प्रति पंक्ति एक से अधिक हो सकता है) वास्तव में पहले हैंडलिंग कोड पर लौटने से पहले, इंटरप्ट को हैंडल करता है।
एडम मारस

ठीक है, इसलिए वास्तव में दो प्रकार के व्यवधान हैं हैंडलर: वे जो प्रोसेसर को कॉल करते हैं (हमेशा do_IRQ ()), और उन कि कर्नेल कॉल (एक का अनुरोध के माध्यम से पंजीकृत किया है i_irq ())। क्या आप इसे अपने उत्तर में जोड़ सकते हैं? मुझे लगता है कि तब मैं इसे स्वीकार करूंगा :) बहुत बहुत धन्यवाद
फिलिप मुरी

1
@PhilippMurry मैं एक विशेषज्ञ नहीं हूँ कि कैसे लिनक्स हैंडल बाधित होता है (और कर्नेल डेवलपर्स उस सिस्टम में कैसे टैप करते हैं) लेकिन मैंने कुछ और जानकारी को और अधिक व्यापक अर्थों में जोड़ा कि कैसे कर्नेल का अपना ISR प्रबंधन हो सकता है।
एडम मारस

12

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

विवरण अलग-अलग प्रोसेसर पर अलग-अलग होते हैं, लेकिन प्रोसेसर में एक बाधा को संभालने के लिए मुख्य सामान्य तत्व हैं:

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

1

अन्य दो उत्तर (लेखन के समय) इंटरप्ट और आईडीटी के बारे में बात करते हैं। यह सही है, हालांकि, आधुनिक इंटेल-एस्क्यू सीपीयू पर, कर्नेल में कॉल करने के तीन से कम तरीके नहीं हैं।

विधि # 1: बाधित।

यह ऊपर बताया गया है। आप इंटरप्ट डिस्क्रिप्टर टेबल / इंटरप्ट वेक्टर में एक प्रविष्टि सेट करते हैं, और फिर कर्नेल में प्रवेश करने के लिए एक सॉफ्टवेयर इंटरप्ट निष्पादित करते हैं।

इस पद्धति का मुख्य लाभ यह है कि एक विशिष्ट कर्नेल को वैसे भी बाधित करने में सक्षम होने की आवश्यकता होती है, और यह पुरातन हार्डवेयर पर काम करता है।

विधि # 2: कॉल गेट्स।

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

मैं नहीं मानता कि लिनक्स कभी कॉल गेट्स का इस्तेमाल करता था, लेकिन विंडोज 95 ने किया। Win95 कर्नेल सेवाएँ ( krnl386.exeऔर kernel.dll) वास्तव में उपयोगकर्ता मोड (रिंग 3) में चलती थीं। उच्चतम विशेषाधिकार स्तर (रिंग 0) का उपयोग केवल ड्राइवरों और एक माइक्रोकर्नल के लिए किया जाता था जो केवल प्रक्रिया स्विचिंग का प्रदर्शन करते थे। कॉल गेटों का उपयोग करके ड्राइवरों में कॉलिंग की गई। इसने 16-बिट कोड की अनुमति दी (जिसमें से बहुत कुछ था!) ​​Win95 ड्राइवरों का उपयोग करने के लिए बस एक मानक दूर कॉल का उपयोग करना, जैसे उन्होंने हमेशा किया था।

वैश्विक डिस्क्रिप्टर तालिका की अपर्याप्त सुरक्षा कई विंडोज 95 कारनामों का कारण थी, जो स्मृति पर लिखकर अपने स्वयं के कॉल गेट स्थापित करने में कामयाब रहे।

विधि # 3: SYSCALL / SYSRET और SYSENTER / SYSEXIT

ये निर्देश के दो सेट हैं, स्वतंत्र रूप से एएमडी और इंटेल द्वारा आविष्कार किए गए हैं, लेकिन वे अनिवार्य रूप से एक ही काम करते हैं। SYSCALL / SYSRET पहले आया था और केवल AMD, SYSENTER / SYSEXIT इंटेल था, लेकिन AMD अब इसे लागू करता है। इसलिए मैं SYSENTER / SYSEXIT का वर्णन करने जा रहा हूं।

कॉल गेट्स के विपरीत, SYSENTER का उपयोग केवल रिंग 0 में ट्रांसफर करने के लिए किया जा सकता है, और केवल एक स्थान पर ट्रांसफर किया जा सकता है। हालाँकि, इसमें बेहद कम विलंबता होने का फायदा है क्योंकि कॉल या इंटरप्ट के विपरीत यह स्टैक को स्पर्श नहीं करता है।

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

SYSENTER और SYSEXIT निर्देशों के बारे में अधिक जानकारी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.