यूनिक्स में पाइपलाइन कैसे कार्यान्वित की जाती हैं

यह आलेख यूनिक्स कर्नेल में पाइपलाइनों के कार्यान्वयन का वर्णन करता है। मैं कुछ हद तक निराश था कि एक हालिया लेख जिसका शीर्षक था "यूनिक्स में पाइपलाइनें कैसे काम करती हैं?" निकला नहीं आंतरिक संरचना के बारे में मैं उत्सुक हो गया और उत्तर खोजने के लिए पुराने स्रोतों की खोज करने लगा।

हम किस बारे में बात कर रहे हैं?

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

$ echo hello | wc -c
6

यह कार्यक्षमता कर्नेल द्वारा प्रदत्त सिस्टम कॉल पर निर्भर करती है pipe, जिसका वर्णन दस्तावेज़ीकरण पृष्ठों पर किया गया है पाइप(7) и पाइप(2):

पाइपलाइनें अंतर-प्रक्रिया संचार के लिए एक-तरफ़ा चैनल प्रदान करती हैं। पाइपलाइन में एक इनपुट (राइट एंड) और एक आउटपुट (रीड एंड) होता है। पाइपलाइन के इनपुट पर लिखे गए डेटा को आउटपुट पर पढ़ा जा सकता है।

कॉल करके पाइपलाइन बनाई जाती है pipe(2), जो दो फ़ाइल डिस्क्रिप्टर लौटाता है: एक पाइपलाइन के इनपुट को संदर्भित करता है, दूसरा आउटपुट को।

उपरोक्त कमांड से ट्रेस आउटपुट एक पाइपलाइन के निर्माण और उसके माध्यम से एक प्रक्रिया से दूसरी प्रक्रिया में डेटा के प्रवाह को दर्शाता है:

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

मूल प्रक्रिया कॉल करती है pipe()संलग्न फ़ाइल डिस्क्रिप्टर प्राप्त करने के लिए। एक चाइल्ड प्रोसेस एक डिस्क्रिप्टर को लिखता है और दूसरा प्रोसेस दूसरे डिस्क्रिप्टर से वही डेटा पढ़ता है। शेल stdin और stdout से मिलान करने के लिए dup2 के साथ डिस्क्रिप्टर 3 और 4 का "नाम" बदलता है।

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

यदि कोई प्रक्रिया किसी खाली पाइपलाइन से पढ़ने का प्रयास करती है, तो read(2) डेटा उपलब्ध होने तक ब्लॉक रहेगा. यदि कोई प्रक्रिया पूर्ण पाइपलाइन पर लिखने का प्रयास करती है, तो write(2) लेखन पूरा करने के लिए पाइपलाइन से पर्याप्त डेटा पढ़ने तक ब्लॉक रहेगा।

POSIX आवश्यकता की तरह, यह एक महत्वपूर्ण गुण है: पाइपलाइन तक लिखना PIPE_BUF बाइट्स (कम से कम 512) परमाणु होने चाहिए ताकि प्रक्रियाएं पाइपलाइन के माध्यम से एक दूसरे के साथ इस तरह से संचार कर सकें कि सामान्य फाइलें (जो ऐसी गारंटी प्रदान नहीं करती हैं) नहीं कर सकतीं।

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

हम क्या खोज कर रहे हैं?

मैं अपनी उंगलियों पर समझाऊंगा ताकि आपके लिए यह कल्पना करना आसान हो जाए कि एक कन्वेयर कैसे काम कर सकता है। आपको मेमोरी में एक बफ़र और कुछ स्थिति आवंटित करने की आवश्यकता होगी। आपको बफ़र से डेटा जोड़ने और हटाने के लिए फ़ंक्शंस की आवश्यकता होगी। आपको फ़ाइल डिस्क्रिप्टर पर पढ़ने और लिखने के संचालन के दौरान फ़ंक्शन को कॉल करने के लिए कुछ सुविधा की आवश्यकता होगी। और ऊपर वर्णित विशेष व्यवहार को लागू करने के लिए ताले की आवश्यकता होती है।

अब हम अपने अस्पष्ट मानसिक मॉडल की पुष्टि या खंडन करने के लिए उज्ज्वल लैंपलाइट के तहत कर्नेल के स्रोत कोड से पूछताछ करने के लिए तैयार हैं। लेकिन अप्रत्याशित के लिए हमेशा तैयार रहें।

हम कहाँ देख रहे हैं?

मुझे नहीं पता कि प्रसिद्ध पुस्तक की मेरी प्रति कहाँ है।सिंह पुस्तक« यूनिक्स 6 स्रोत कोड के साथ, लेकिन धन्यवाद यूनिक्स हेरिटेज सोसायटी ऑनलाइन खोजा जा सकता है सोर्स कोड यूनिक्स के भी पुराने संस्करण।

टीयूएचएस अभिलेखागार में घूमना एक संग्रहालय में जाने जैसा है। हम अपने साझा इतिहास को देख सकते हैं और मैं पुराने कैसेट और प्रिंटआउट से थोड़ा-थोड़ा करके इस सारी सामग्री को पुनर्प्राप्त करने के वर्षों के प्रयास का सम्मान करता हूं। और मैं उन टुकड़ों से भलीभांति परिचित हूं जो अभी भी गायब हैं।

पाइपलाइनों के प्राचीन इतिहास के बारे में अपनी जिज्ञासा को संतुष्ट करने के बाद, हम तुलना के लिए आधुनिक कोर को देख सकते हैं।

संयोग से, pipe तालिका में सिस्टम कॉल नंबर 42 है sysent[]. संयोग?

पारंपरिक यूनिक्स कर्नेल (1970-1974)

मुझे कोई निशान नहीं मिला pipe(2) न तो में पीडीपी-7 यूनिक्स (जनवरी 1970), न ही में पहला संस्करण यूनिक्स (नवंबर 1971), न ही अपूर्ण स्रोत कोड में दूसरा संस्करण (जून 1972)।

टीयूएचएस का दावा है कि तीसरा संस्करण यूनिक्स (फरवरी 1973) पाइपलाइनों वाला पहला संस्करण था:

यूनिक्स का तीसरा संस्करण असेंबलर में लिखे गए कर्नेल वाला अंतिम संस्करण था, लेकिन पाइपलाइनों वाला पहला संस्करण भी था। 1973 के दौरान, तीसरे संस्करण को बेहतर बनाने के लिए काम चल रहा था, कर्नेल को सी में फिर से लिखा गया था, और इस तरह यूनिक्स के चौथे संस्करण का जन्म हुआ।

एक पाठक को एक दस्तावेज़ का स्कैन मिला जिसमें डौग मैकलरॉय ने "बगीचे की नली की तरह कार्यक्रमों को जोड़ने" का विचार प्रस्तावित किया था।

ब्रायन कर्निघन की किताब मेंयूनिक्स: एक इतिहास और एक संस्मरण”, पाइपलाइनों की उपस्थिति के इतिहास में, इस दस्तावेज़ का भी उल्लेख किया गया है: “… यह 30 वर्षों तक बेल लैब्स में मेरे कार्यालय में दीवार पर लटका रहा।” यहाँ मैकिलॉय के साथ साक्षात्कारऔर दूसरी कहानी से मैकिलॉय का काम, 2014 में लिखा गया:

जब यूनिक्स सामने आया, तो कोरटाइन के प्रति मेरे जुनून ने मुझे ओएस लेखक, केन थॉम्पसन से कुछ प्रक्रिया में लिखे गए डेटा को न केवल डिवाइस तक जाने की अनुमति देने के लिए कहा, बल्कि किसी अन्य प्रक्रिया से बाहर निकलने की भी अनुमति दी। केन ने सोचा कि यह संभव है। हालाँकि, एक न्यूनतमवादी के रूप में, वह चाहते थे कि प्रत्येक सिस्टम सुविधा एक महत्वपूर्ण भूमिका निभाए। क्या प्रक्रियाओं के बीच सीधा लेखन किसी मध्यवर्ती फ़ाइल पर लिखने की तुलना में वास्तव में एक बड़ा लाभ है? और केवल जब मैंने आकर्षक नाम "पाइपलाइन" और प्रक्रियाओं की बातचीत के वाक्यविन्यास के विवरण के साथ एक विशिष्ट प्रस्ताव रखा, तो केन ने अंततः कहा: "मैं यह करूंगा!"।

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

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

हमारे पास इसके लिए दस्तावेज़ीकरण पाठ है pipe(2) दोनों रिलीज़ों से, इसलिए आप दस्तावेज़ खोजकर शुरुआत कर सकते हैं तीसरा संस्करण (कुछ शब्दों के लिए, "मैन्युअल रूप से" रेखांकित, ^H अक्षर की एक स्ट्रिंग जिसके बाद एक अंडरस्कोर होता है!)। यह आद्य-pipe(2) असेंबलर में लिखा गया है और केवल एक फ़ाइल डिस्क्रिप्टर लौटाता है, लेकिन पहले से ही अपेक्षित मुख्य कार्यक्षमता प्रदान करता है:

सिस्टम कॉल पाइप एक I/O तंत्र बनाता है जिसे पाइपलाइन कहा जाता है। लौटाए गए फ़ाइल डिस्क्रिप्टर का उपयोग पढ़ने और लिखने के संचालन के लिए किया जा सकता है। जब पाइपलाइन में कुछ लिखा जाता है, तो यह 504 बाइट्स डेटा तक बफ़र करता है, जिसके बाद लेखन प्रक्रिया निलंबित हो जाती है। पाइपलाइन से पढ़ते समय, बफ़र किया गया डेटा लिया जाता है।

अगले वर्ष तक, कर्नेल को सी में फिर से लिखा गया था, और पाइप(2) चौथा संस्करण प्रोटोटाइप के साथ अपना आधुनिक स्वरूप प्राप्त किया "pipe(fildes)»:

सिस्टम कॉल पाइप एक I/O तंत्र बनाता है जिसे पाइपलाइन कहा जाता है। लौटाए गए फ़ाइल डिस्क्रिप्टर का उपयोग पढ़ने और लिखने के संचालन में किया जा सकता है। जब पाइपलाइन में कुछ लिखा जाता है, तो r1 (resp. fildes[1]) में लौटाए गए डिस्क्रिप्टर का उपयोग किया जाता है, 4096 बाइट्स डेटा तक बफर किया जाता है, जिसके बाद लिखने की प्रक्रिया निलंबित कर दी जाती है। पाइपलाइन से पढ़ते समय, डिस्क्रिप्टर r0 (resp. fildes[0]) पर लौट आता है और डेटा लेता है।

यह माना जाता है कि एक बार एक पाइपलाइन परिभाषित हो जाने के बाद, दो (या अधिक) इंटरैक्टिंग प्रक्रियाएं (बाद के आमंत्रणों द्वारा निर्मित) होती हैं कांटा) कॉल का उपयोग करके पाइपलाइन से डेटा पास करेगा पढ़ना и लिखना.

शेल में पाइपलाइन के माध्यम से जुड़ी प्रक्रियाओं की एक रैखिक सरणी को परिभाषित करने के लिए एक वाक्यविन्यास होता है।

एक खाली पाइपलाइन (जिसमें कोई बफ़र किया गया डेटा नहीं है) से पढ़ने के लिए कॉल जिसका केवल एक सिरा है (सभी लिखने वाले फ़ाइल डिस्क्रिप्टर बंद हैं) "फ़ाइल का अंत" लौटाते हैं। समान स्थिति में राइट कॉल को नजरअंदाज कर दिया जाता है।

जल्द से जल्द संरक्षित पाइपलाइन कार्यान्वयन लागू होता है यूनिक्स के पांचवें संस्करण के लिए (जून 1974), लेकिन यह लगभग उसी के समान है जो अगली रिलीज़ में दिखाई दिया। केवल टिप्पणियाँ जोड़ी गईं, इसलिए पाँचवें संस्करण को छोड़ा जा सकता है।

यूनिक्स छठा संस्करण (1975)

यूनिक्स स्रोत कोड पढ़ना प्रारंभ करें छठा संस्करण (मई 1975) को बहुत-बहुत धन्यवाद लायंस पिछले संस्करणों के स्रोतों की तुलना में इसे ढूंढना बहुत आसान है:

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

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

15 वर्ष से भी पहले, मैंने इसमें दिए गए स्रोत कोड की एक प्रति टाइप की थी लायंसक्योंकि मुझे अज्ञात संख्या में अन्य प्रतियों से अपनी प्रति की गुणवत्ता पसंद नहीं आई। टीयूएचएस अभी तक अस्तित्व में नहीं था, और मेरे पास पुराने स्रोतों तक पहुंच नहीं थी। लेकिन 1988 में मुझे 9 ट्रैक वाला एक पुराना टेप मिला जिसमें पीडीपी11 कंप्यूटर का बैकअप था। यह जानना कठिन था कि यह काम करता है या नहीं, लेकिन एक अक्षुण्ण /usr/src/ पेड़ था जिसमें अधिकांश फ़ाइलों पर 1979 अंकित था, जो तब भी प्राचीन दिखता था। मैंने सोचा, यह सातवां संस्करण या पीडब्लूबी व्युत्पन्न था।

मैंने खोज को आधार के रूप में लिया और स्रोतों को छठे संस्करण की स्थिति में मैन्युअल रूप से संपादित किया। कोड का कुछ हिस्सा वही रहा, कुछ को थोड़ा संपादित करना पड़ा, आधुनिक टोकन += को अप्रचलित =+ में बदल दिया गया। कुछ को बस हटा दिया गया था, और कुछ को पूरी तरह से फिर से लिखना पड़ा, लेकिन बहुत ज्यादा नहीं।

और आज हम छठे संस्करण का स्रोत कोड टीयूएचएस पर ऑनलाइन पढ़ सकते हैं पुरालेख, जिसमें डेनिस रिची का हाथ था.

वैसे, पहली नज़र में, कर्निघन और रिची के काल से पहले के सी-कोड की मुख्य विशेषता इसकी है संक्षिप्तता. ऐसा अक्सर नहीं होता है कि मैं अपनी साइट पर अपेक्षाकृत संकीर्ण प्रदर्शन क्षेत्र को फिट करने के लिए व्यापक संपादन के बिना कोड के स्निपेट डालने में सक्षम हूं।

शीघ्र /usr/sys/ken/pipe.c एक व्याख्यात्मक टिप्पणी है (और हाँ, और भी बहुत कुछ है /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

चौथे संस्करण के बाद से बफ़र का आकार नहीं बदला है। लेकिन यहां हम देखते हैं, बिना किसी सार्वजनिक दस्तावेज के, कि पाइपलाइनें एक बार फ़ाइलों को फ़ॉलबैक स्टोरेज के रूप में उपयोग करती थीं!

जहाँ तक LARG फ़ाइलों का प्रश्न है, वे इसके अनुरूप हैं इनोड-ध्वज LARG, जिसे प्रोसेस करने के लिए "बड़े एड्रेसिंग एल्गोरिदम" द्वारा उपयोग किया जाता है अप्रत्यक्ष ब्लॉक बड़े फ़ाइल सिस्टम का समर्थन करने के लिए। चूंकि केन ने कहा कि उनका उपयोग न करना ही बेहतर है, इसलिए मुझे उनकी बात मानकर खुशी होगी।

यहाँ वास्तविक सिस्टम कॉल है pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

टिप्पणी स्पष्ट रूप से बताती है कि यहाँ क्या हो रहा है। लेकिन कोड को समझना इतना आसान नहीं है, आंशिक रूप से इसकी वजह यह है कि "संरचना उपयोगकर्ता यू» और रजिस्टर R0 и R1 सिस्टम कॉल पैरामीटर और रिटर्न मान पारित किए जाते हैं।

आइए साथ प्रयास करें ialloc() डिस्क पर रखें इनोड (इनोड), और मदद से फ़ैलोक() - दुकान दो फ़ाइल. यदि सब कुछ ठीक रहा, तो हम इन फ़ाइलों को पाइपलाइन के दो सिरों के रूप में पहचानने के लिए झंडे सेट करेंगे, उन्हें एक ही इनोड (जिसकी संदर्भ संख्या 2 हो जाती है) पर इंगित करेंगे, और इनोड को संशोधित और उपयोग में चिह्नित करेंगे। के अनुरोधों पर ध्यान दें मैंने डाला() नए इनोड में संदर्भ संख्या को कम करने के लिए त्रुटि पथों में।

pipe() के माध्यम से देय R0 и R1 पढ़ने और लिखने के लिए रिटर्न फ़ाइल डिस्क्रिप्टर नंबर। falloc() फ़ाइल संरचना में एक सूचक लौटाता है, लेकिन इसके माध्यम से "वापस" भी देता है u.u_ar0[R0] और एक फ़ाइल डिस्क्रिप्टर। यानी कोड को स्टोर किया जाता है r पढ़ने के लिए फ़ाइल डिस्क्रिप्टर और सीधे लिखने के लिए एक डिस्क्रिप्टर निर्दिष्ट करता है u.u_ar0[R0] दूसरी कॉल के बाद falloc().

झंडा FPIPE, जिसे हम पाइपलाइन बनाते समय सेट करते हैं, फ़ंक्शन के व्यवहार को नियंत्रित करता है sys2.c में rdwr(), जो विशिष्ट I/O रूटीन को कॉल करता है:

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

फिर फ़ंक्शन readp() в pipe.c पाइपलाइन से डेटा पढ़ता है। लेकिन कार्यान्वयन की शुरुआत का पता लगाना बेहतर है writep(). फिर, तर्क पारित करने की परंपरा की प्रकृति के कारण कोड अधिक जटिल हो गया है, लेकिन कुछ विवरण छोड़े जा सकते हैं।

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

हम पाइपलाइन इनपुट के लिए बाइट्स लिखना चाहते हैं u.u_count. सबसे पहले हमें इनोड को लॉक करना होगा (नीचे देखें)। plock/prele).

फिर हम इनोड संदर्भ गणना की जांच करते हैं। जब तक पाइपलाइन के दोनों सिरे खुले रहते हैं, काउंटर 2 होना चाहिए। हम एक लिंक (से) को पकड़कर रखते हैं rp->f_inode), इसलिए यदि काउंटर 2 से कम है, तो इसका मतलब यह होना चाहिए कि रीडिंग प्रक्रिया ने पाइपलाइन का अपना अंत बंद कर दिया है। दूसरे शब्दों में, हम एक बंद पाइपलाइन को लिखने का प्रयास कर रहे हैं, जो एक गलती है। पहला त्रुटि कोड EPIPE और संकेत SIGPIPE यूनिक्स के छठे संस्करण में दिखाई दिया।

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

यदि पाइपलाइन में पर्याप्त खाली जगह है, तो हम इसका उपयोग करके डेटा लिखते हैं लिखना(). पैरामीटर i_size1 इनोड'ए (एक खाली पाइपलाइन के साथ 0 के बराबर हो सकता है) उस डेटा के अंत को इंगित करता है जो इसमें पहले से मौजूद है। यदि लिखने के लिए पर्याप्त जगह है, तो हम पाइपलाइन भर सकते हैं i_size1 से PIPESIZ. फिर हम लॉक जारी करते हैं और पाइपलाइन से पढ़ने की प्रतीक्षा कर रही किसी भी प्रक्रिया को जगाने का प्रयास करते हैं। हम यह देखने के लिए शुरुआत में वापस जाते हैं कि क्या हम उतने बाइट्स लिखने में कामयाब रहे जितनी हमें ज़रूरत थी। यदि नहीं, तो हम एक नया रिकॉर्डिंग चक्र शुरू करते हैं।

आमतौर पर पैरामीटर i_mode इनोड का उपयोग अनुमतियों को संग्रहीत करने के लिए किया जाता है r, w и x. लेकिन पाइपलाइनों के मामले में, हम संकेत देते हैं कि कुछ प्रक्रिया बिट्स का उपयोग करके लिखने या पढ़ने की प्रतीक्षा कर रही है IREAD и IWRITE क्रमश। प्रक्रिया ध्वज सेट करती है और कॉल करती है sleep(), और उम्मीद है कि भविष्य में कोई अन्य प्रक्रिया कॉल करेगी wakeup().

असली जादू होता है sleep() и wakeup(). में इन्हें क्रियान्वित किया जाता है एसएलपी.सी, प्रसिद्ध "आपसे इसे समझने की उम्मीद नहीं है" टिप्पणी का स्रोत। सौभाग्य से, हमें कोड को समझने की ज़रूरत नहीं है, बस कुछ टिप्पणियाँ देखें:

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

वह प्रक्रिया जो कॉल करती है sleep() किसी विशेष चैनल के लिए, बाद में किसी अन्य प्रक्रिया द्वारा जागृत किया जा सकता है, जो कॉल करेगी wakeup() उसी चैनल के लिए. writep() и readp() ऐसी युग्मित कॉलों के माध्यम से अपने कार्यों का समन्वय करें। ध्यान दें कि pipe.c हमेशा प्राथमिकता दें PPIPE जब बुलाया गया sleep(), तो सभी sleep() एक सिग्नल द्वारा बाधित किया जा सकता है।

अब हमारे पास फ़ंक्शन को समझने के लिए सब कुछ है readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

आपको इस फ़ंक्शन को नीचे से ऊपर तक पढ़ना आसान हो सकता है। "रीड एंड रिटर्न" शाखा का उपयोग आमतौर पर तब किया जाता है जब पाइपलाइन में कुछ डेटा होता है। इस मामले में, हम उपयोग करते हैं पढ़ना() वर्तमान डेटा से आरंभ करके उतना ही डेटा पढ़ें जितना उपलब्ध है f_offset पढ़ें, और फिर संबंधित ऑफसेट का मान अपडेट करें।

बाद के रीड्स पर, यदि रीड ऑफसेट पहुंच गया है तो पाइपलाइन खाली हो जाएगी i_size1 इनोड पर. हम स्थिति को 0 पर रीसेट करते हैं और किसी भी प्रक्रिया को जगाने का प्रयास करते हैं जो पाइपलाइन पर लिखना चाहता है। हम जानते हैं कि जब कन्वेयर भर जाता है, writep() पर सो जाओ ip+1. और अब जबकि पाइपलाइन खाली है, हम इसके लेखन चक्र को फिर से शुरू करने के लिए इसे जगा सकते हैं।

अगर पढ़ने को कुछ नहीं है तो readp() एक झंडा लगा सकते हैं IREAD और सो जाओ ip+2. हम जानते हैं कि उसे क्या जगाएगा writep()जब यह पाइपलाइन में कुछ डेटा लिखता है।

पर टिप्पणी पढ़ें() और लिखेंi() आपको यह समझने में मदद मिलेगी कि मापदंडों को पारित करने के बजाय "u» हम उन्हें नियमित I/O फ़ंक्शंस की तरह मान सकते हैं जो एक फ़ाइल, एक स्थिति, मेमोरी में एक बफर लेते हैं, और पढ़ने या लिखने के लिए बाइट्स की संख्या की गणना करते हैं।

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

जहाँ तक "रूढ़िवादी" अवरोधन का प्रश्न है readp() и writep() इनोड को तब तक लॉक करें जब तक कि वे समाप्त न हो जाएं या परिणाम प्राप्त न कर लें (अर्थात कॉल करें)। wakeup). plock() и prele() सरलता से काम करें: कॉल के एक अलग सेट का उपयोग करें sleep и wakeup हमें किसी भी प्रक्रिया को जागृत करने की अनुमति दें जिसके लिए हमारे द्वारा अभी जारी किए गए लॉक की आवश्यकता है:

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

पहले तो मुझे समझ नहीं आया कि ऐसा क्यों है readp() कारण नहीं है prele(ip) कॉल से पहले wakeup(ip+1). पहली चीज़ writep() इसके लूप में कॉल करता है, यह plock(ip), जिसके परिणामस्वरूप गतिरोध उत्पन्न होता है readp() अभी तक अपना ब्लॉक नहीं हटाया है, इसलिए कोड को किसी तरह सही ढंग से काम करना चाहिए। यदि आप देखें wakeup(), यह स्पष्ट हो जाता है कि यह केवल सोने की प्रक्रिया को निष्पादन के लिए तैयार के रूप में चिह्नित करता है, ताकि भविष्य में sched() वास्तव में इसे लॉन्च किया। इसलिए readp() का कारण बनता है wakeup(), अनलॉक, सेट IREAD और कॉल करता है sleep(ip+2)- यह सब पहले writep() चक्र पुनः प्रारंभ करता है.

यह छठे संस्करण में पाइपलाइनों का विवरण पूरा करता है। सरल कोड, दूरगामी प्रभाव।

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

Xv6, एक सरल यूनिक्स जैसा कर्नेल

एक नाभिक बनाने के लिए Xv6 यूनिक्स के छठे संस्करण से प्रभावित, लेकिन x86 प्रोसेसर पर चलने के लिए आधुनिक सी में लिखा गया। कोड को पढ़ना और समझना आसान है। इसके अलावा, टीयूएचएस के साथ यूनिक्स स्रोतों के विपरीत, आप इसे संकलित कर सकते हैं, संशोधित कर सकते हैं और इसे पीडीपी 11/70 के अलावा किसी अन्य चीज़ पर चला सकते हैं। इसलिए, इस कोर का व्यापक रूप से विश्वविद्यालयों में ऑपरेटिंग सिस्टम पर शिक्षण सामग्री के रूप में उपयोग किया जाता है। सूत्रों का कहना है Github पर हैं.

कोड में स्पष्ट और विचारशील कार्यान्वयन शामिल है पाइप.सी, डिस्क पर इनोड के बजाय मेमोरी में एक बफर द्वारा समर्थित। यहां मैं केवल "संरचनात्मक पाइपलाइन" और फ़ंक्शन की परिभाषा देता हूं pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() शेष सभी कार्यान्वयन की स्थिति निर्धारित करता है, जिसमें फ़ंक्शंस शामिल हैं piperead(), pipewrite() и pipeclose(). वास्तविक सिस्टम कॉल sys_pipe में लागू किया गया एक रैपर है sysfile.c. मैं उसके सभी कोड को पढ़ने की सलाह देता हूं। जटिलता छठे संस्करण के स्रोत कोड के स्तर पर है, लेकिन यह पढ़ने में बहुत आसान और अधिक सुखद है।

लिनक्स 0.01

आप Linux 0.01 के लिए स्रोत कोड पा सकते हैं। इसमें पाइपलाइनों के कार्यान्वयन का अध्ययन करना शिक्षाप्रद होगा fs/pipe.c. यहां, पाइपलाइन का प्रतिनिधित्व करने के लिए एक इनोड का उपयोग किया जाता है, लेकिन पाइपलाइन स्वयं आधुनिक सी में लिखी गई है। यदि आपने छठे संस्करण कोड के माध्यम से अपना रास्ता हैक कर लिया है, तो आपको यहां कोई परेशानी नहीं होगी। फ़ंक्शन इस प्रकार दिखता है write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

यहां तक ​​कि संरचना परिभाषाओं को देखे बिना भी, आप यह पता लगा सकते हैं कि इनोड संदर्भ गणना का उपयोग यह जांचने के लिए कैसे किया जाता है कि लिखने के ऑपरेशन का परिणाम होता है या नहीं SIGPIPE. बाइट-बाय-बाइट कार्य के अलावा, इस फ़ंक्शन की तुलना उपरोक्त विचारों से करना आसान है। यहां तक ​​कि तर्क भी sleep_on/wake_up इतना पराया नहीं लगता.

आधुनिक लिनक्स कर्नेल, फ्रीबीएसडी, नेटबीएसडी, ओपनबीएसडी

मैं जल्दी से कुछ आधुनिक गुठली पर गया। उनमें से किसी के पास पहले से ही डिस्क-आधारित कार्यान्वयन नहीं है (आश्चर्य की बात नहीं)। लिनक्स का अपना कार्यान्वयन है। और यद्यपि तीन आधुनिक बीएसडी कर्नेल में जॉन डायसन द्वारा लिखे गए कोड पर आधारित कार्यान्वयन शामिल हैं, लेकिन पिछले कुछ वर्षों में वे एक-दूसरे से बहुत अलग हो गए हैं।

पढ़ने के लिए fs/pipe.c (लिनक्स पर) या sys/kern/sys_pipe.c (*बीएसडी पर), इसके लिए वास्तविक समर्पण की आवश्यकता होती है। वेक्टर और एसिंक्रोनस I/O जैसी सुविधाओं के लिए प्रदर्शन और समर्थन आज कोड में महत्वपूर्ण हैं। और मेमोरी आवंटन, लॉक और कर्नेल कॉन्फ़िगरेशन का विवरण बहुत भिन्न होता है। ऑपरेटिंग सिस्टम पर परिचयात्मक पाठ्यक्रम के लिए विश्वविद्यालयों को इसकी आवश्यकता नहीं है।

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

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

स्रोत: www.habr.com