जवाबों:
किसी भी I / O को एक प्रक्रिया द्वारा लागू सिस्टम कॉल द्वारा नियंत्रित किया जाता है। आखिरकार इस तरह के एक सिस्टम कॉल वास्तविक I / O ऑपरेशन को करने के लिए कुछ उपयुक्त निम्न-स्तरीय डिवाइस ड्राइवर फ़ंक्शन के लिए अपना रास्ता नीचे कर देगा।
I / O मुश्किल हो सकता है - वास्तव में डिवाइस के अंदर और बाहर डेटा प्राप्त करने के लिए, विभिन्न चरणों का पालन करने की आवश्यकता हो सकती है, क्रम में और संभवतः समय की आवश्यकताओं के साथ। अगर ये चरण परमाणु रूप से पूरे नहीं होते हैं, तो अगली बार जब वे कोशिश करते हैं, तो डिवाइस प्रतिक्रिया नहीं दे सकता है, दुर्व्यवहार कर सकता है, या सिस्टम लॉकअप का कारण बन सकता है। ये चरण प्रत्येक डिवाइस के लिए अलग और अद्वितीय हो सकते हैं, इसलिए बहुत सारे डिवाइस ड्राइवर क्यों हैं।
एक अच्छी तरह से लिखा डिवाइस ड्राइवर को पता होना चाहिए कि जिस डिवाइस को सेवा देने की कोशिश की जा रही है, उससे कैसे निपटना है, इसलिए इसे सामान्य रूप से समस्याओं का अनुभव नहीं करना चाहिए जब तक कि ड्राइवर बग न हो, आप डिवाइस के लिए गलत ड्राइवर का उपयोग कर रहे हैं, या भौतिक डिवाइस विफल हो रहा है।
अब जब मैंने मौरिस बाख की पुस्तक "द डिज़ाइन ऑफ़ द यूनिक्स ऑपरेटिंग सिस्टम" पढ़ी है, तो मुझे इस प्रश्न का उत्तर स्वयं देना चाहिए।
संक्षेप में, I / O को अबाधित बनाना है I / O टास्क खत्म करने के लिए ASAP बनाने के उद्देश्य से, बिना संकेतों के हस्तक्षेप किए बिना।
कुछ संबंधित ज्ञान जो मैंने पुस्तक से प्राप्त किए हैं:
कर्नेल में कुछ कोड पथ निर्बाध रूप से चिह्नित किए जाते हैं, ज्यादातर क्योंकि कोड को सख्त समय (डिवाइस का जवाब देने के लिए) का पालन करना पड़ता है या क्योंकि यह कुछ ऐसा कर रहा है जो हस्तक्षेप को स्वीकार नहीं करता है। लिनक्स के मामले में, अधिकांश को पहले स्वतंत्र-कर्नेल treads में धकेल दिया गया है, और दूसरे को अधिकतर समाप्त कर दिया गया है (मुझे संदेह है कि वर्तमान मल्टी-सीपीयू मशीनों के दबाव में ज्यादातर)। यानी, अब कुछ समय हो गया है कि मैंने अबाधित नींद में एक प्रक्रिया नहीं देखी है।
write(2)को जल्दी लौटने की अनुमति है, लिखित बाइट काउंट को वापस लौटाया जा सकता है, जो 3 जी आर्ग के रूप में पारित बफर लंबाई से कम हो सकता है।