कसरी पाइपलाइनहरू Unix मा लागू गरिन्छ

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

हामी के कुरा गर्दैछौं?

पाइपलाइनहरू, "सम्भवतः युनिक्समा सबैभन्दा महत्त्वपूर्ण आविष्कार," साना कार्यक्रमहरू एकसाथ जोड्ने अन्तर्निहित युनिक्स दर्शनको परिभाषित विशेषता हो, साथै कमाण्ड लाइनमा परिचित चिन्ह:

$ echo hello | wc -c
6

यो कार्यक्षमता कर्नेल-प्रदान गरिएको प्रणाली कलमा निर्भर गर्दछ pipe, जुन कागजात पृष्ठहरूमा वर्णन गरिएको छ पाइप(७) и पाइप(७):

पाइपलाइनहरूले अन्तरप्रक्रिया सञ्चारको लागि एक दिशाहीन च्यानल प्रदान गर्दछ। पाइपलाइनमा इनपुट (अन्त लेख्नुहोस्) र आउटपुट (अन्त पढ्नुहोस्) छ। पाइपलाइनको इनपुटमा लेखिएको डाटा आउटपुटमा पढ्न सकिन्छ।

पाइपलाइन कल प्रयोग गरेर सिर्जना गरिएको छ 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 मिलाउन वर्णनकर्ता 2 र 3 लाई "रिनाम" गर्न dup4 प्रयोग गर्दछ।

पाइपहरू बिना, शेलले फाइलमा एउटा प्रक्रियाको नतिजा लेख्नुपर्छ र फाइलबाट डाटा पढ्न अर्को प्रक्रियामा पास गर्नुपर्छ। नतिजाको रूपमा, हामी थप स्रोतहरू र डिस्क ठाउँ बर्बाद गर्नेछौं। यद्यपि, पाइपलाइनहरू राम्रो छन् किनभने तिनीहरूले तपाईंलाई अस्थायी फाइलहरूको प्रयोगबाट बच्न अनुमति दिन्छ:

यदि प्रक्रिया खाली पाइपलाइनबाट पढ्न प्रयास गर्दैछ भने read(2) डाटा उपलब्ध नभएसम्म अवरुद्ध हुनेछ। यदि प्रक्रियाले पूर्ण पाइपलाइनमा लेख्ने प्रयास गर्छ भने write(2) लेख्नका लागि पाइपलाइनबाट पर्याप्त डाटा नपढेसम्म ब्लक गर्नेछ।

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

नियमित फाइल प्रयोग गर्दा, एक प्रक्रियाले यसको सबै आउटपुट लेख्न सक्छ र यसलाई अर्को प्रक्रियामा पास गर्न सक्छ। वा प्रक्रियाहरूले उच्च समानान्तर मोडमा काम गर्न सक्छन्, बाह्य सङ्केत प्रणाली (जस्तै सेमाफोर) प्रयोग गरेर लेख्न वा पढिसकेपछि एक अर्कालाई सूचित गर्न। कन्भेयरहरूले हामीलाई यो सबै झन्झटबाट बचाउँछन्।

हामी के खोजिरहेका छौं?

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

अब हामी हाम्रो अस्पष्ट मानसिक मोडेल पुष्टि गर्न वा खण्डन गर्न उज्यालो बत्ती अन्तर्गत कर्नेल स्रोत कोड सोधपुछ गर्न तयार छौं। तर सधैं अप्रत्याशित लागि तयार रहनुहोस्।

हामी कहाँ हेरिरहेका छौं?

मलाई थाहा छैन मेरो प्रसिद्ध पुस्तकको प्रतिलिपि कहाँ छ "लायन्स किताब"युनिक्स 6 स्रोत कोडको साथ, तर धन्यवाद युनिक्स हेरिटेज सोसाइटी मा अनलाइन खोज्न सक्नुहुन्छ स्रोत कोड युनिक्स को पुराना संस्करणहरु।

TUHS अभिलेखहरूमा घुम्नु भनेको संग्रहालय भ्रमण गर्नु जस्तै हो। हामी हाम्रो साझा इतिहास हेर्न सक्छौं, र मलाई पुराना टेप र छापहरूबाट यी सबै सामग्रीहरू अलि-अलि रिकभर गर्न धेरै वर्षको प्रयासको लागि सम्मान छ। र अझै हराइरहेको ती टुक्राहरूको बारेमा म तीव्र रूपमा सचेत छु।

कन्वेयरहरूको पुरानो इतिहासको बारेमा हाम्रो जिज्ञासालाई सन्तुष्ट पार्दै, हामी तुलनाको लागि आधुनिक कर्नेलहरू हेर्न सक्छौं।

वैसे, pipe तालिकामा प्रणाली कल नम्बर 42 हो sysent[]। संयोग ?

परम्परागत युनिक्स कर्नेल (1970-1974)

मैले कुनै निशान फेला पारेन pipe(2) न त भित्र PDP-7 Unix (जनवरी 1970), न त मा युनिक्स को पहिलो संस्करण (नोभेम्बर 1971), न त अपूर्ण स्रोत कोडमा दोस्रो संस्करण (जुन १९७२)।

TUHS ले जनाएको छ युनिक्स को तेस्रो संस्करण (फेब्रुअरी 1973) कन्वेयरहरूको साथ पहिलो संस्करण बन्यो:

Unix 1973rd संस्करण विधानसभा भाषामा लेखिएको कर्नेलको साथ अन्तिम संस्करण थियो, तर पाइपलाइनहरू सहितको पहिलो संस्करण पनि थियो। XNUMX को समयमा, तेस्रो संस्करण सुधार गर्न काम गरिएको थियो, कर्नेल सी मा पुन: लेखिएको थियो, र यसैले Unix को चौथो संस्करण देखा पर्यो।

एक पाठकले कागजातको स्क्यान फेला पारे जसमा डग म्याकइल्रोयले "गार्डेन होज जस्तै कार्यक्रमहरू जडान गर्ने" विचार प्रस्ताव गरे।

ब्रायन केर्निघनको पुस्तकमायुनिक्स: एक इतिहास र एक संस्मरण", कन्भेयरहरूको उदयको इतिहासमा, यो कागजात पनि उल्लेख गरिएको छ: "... यो 30 वर्षको लागि बेल ल्याब्सको मेरो कार्यालयको भित्तामा झुण्डिएको थियो।" यहाँ McIlroy संग साक्षात्कार, र अर्को कथा बाट McIlroy को काम, 2014 मा लेखिएको:

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

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

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

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

प्रणाली कल पाइप पाइपलाइन भनिने इनपुट/आउटपुट मेकानिजम सिर्जना गर्दछ। फिर्ता गरिएको फाइल वर्णनकर्ता पढ्न र लेख्ने अपरेशनहरूको लागि प्रयोग गर्न सकिन्छ। जब पाइपलाइनमा केहि लेखिएको छ, डाटाको 504 बाइट सम्म बफर गरिन्छ, जस पछि लेखन प्रक्रिया निलम्बित हुन्छ। पाइपलाइनबाट पढ्दा, बफर गरिएको डाटा हटाइन्छ।

अर्को वर्ष सम्म कर्नेल C मा पुन: लेखिएको थियो, र पाइप (२) चौथो संस्करणमा प्रोटोटाइप संग यसको आधुनिक उपस्थिति प्राप्त गर्यो "pipe(fildes)"

प्रणाली कल पाइप पाइपलाइन भनिने इनपुट/आउटपुट मेकानिजम सिर्जना गर्दछ। फर्काइएको फाइल वर्णनकर्ताहरू पढ्न र लेख्ने कार्यहरूमा प्रयोग गर्न सकिन्छ। जब पाइपलाइनमा केहि लेखिएको छ, r1 (resp. fildes[1]) मा फर्काइएको ह्यान्डल प्रयोग गरिन्छ, डाटाको 4096 बाइटहरूमा बफर गरिन्छ, त्यसपछि लेखन प्रक्रिया निलम्बित हुन्छ। पाइपलाइनबाट पढ्दा, r0 (resp. fildes[0]) मा फर्किएको ह्यान्डलले डाटा लिन्छ।

यो मानिन्छ कि एक पटक पाइपलाइन परिभाषित भएपछि, दुई (वा बढी) सञ्चार प्रक्रियाहरू (पछिल्लो कलहरूद्वारा सिर्जना गरिएको। फोर्क) कल प्रयोग गरेर पाइपलाइनबाट डाटा स्थानान्तरण गर्नेछ पढ्नुहोस и लेख्न.

शेलसँग पाइपलाइनद्वारा जडान गरिएका प्रक्रियाहरूको रैखिक एरे परिभाषित गर्नको लागि वाक्यविन्यास छ।

खाली पाइपलाइनबाट पढ्नका लागि कलहरू (कुनै बफर गरिएको डाटा समावेश छैन) जसमा एउटा मात्र छेउ छ (सबै लेखन फाइल वर्णनकर्ताहरू बन्द छन्) "फाइलको अन्त्य" फर्काउँछ। यस्तै अवस्थामा लेख्नको लागि कलहरू बेवास्ता गरिन्छ।

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

युनिक्सको छैटौं संस्करण (१९७५)

युनिक्स स्रोत कोड पढ्न सुरु गरौं छैटौं संस्करण (मे १९७५)। धेरै हदसम्म धन्यवाद सिंह यो पहिलेको संस्करण को स्रोतहरु भन्दा फेला पार्न धेरै सजिलो छ:

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

आज तपाईंले पुस्तकको पुन: प्रिन्ट किन्न सक्नुहुन्छ, जसको आवरणले विद्यार्थीहरूलाई प्रतिलिपि मेसिनमा देखाउँछ। र वारेन टुमीलाई धन्यवाद (जसले TUHS परियोजना सुरु गर्नुभयो) तपाईंले डाउनलोड गर्न सक्नुहुन्छ छैटौं संस्करणको लागि स्रोत कोडको साथ PDF फाइल। म तपाईंलाई फाइल सिर्जना गर्न कति प्रयास गयो भन्ने एक विचार दिन चाहन्छु:

15 बर्ष भन्दा पहिले, मैले दिएको स्रोत कोडको प्रतिलिपि टाइप गरें सिंह, किनभने मलाई अन्य प्रतिलिपिहरूको अज्ञात संख्याबाट मेरो प्रतिलिपिको गुणस्तर मन परेन। TUHS अहिलेसम्म अवस्थित थिएन र मसँग पुराना स्रोतहरूमा पहुँच थिएन। तर 1988 मा, मैले पुरानो 9-ट्र्याक टेप फेला पारें जसमा PDP11 कम्प्युटरबाट ब्याकअप थियो। यो काम गरिरहेको छ कि भनेर बताउन गाह्रो थियो, तर त्यहाँ एक अक्षुण्ण /usr/src/ रूख थियो जसमा धेरै जसो फाइलहरूमा 1979 सालको लेबल लगाइएको थियो, जुन त्यतिबेला पनि पुरानो देखिन्थ्यो। यो सातौं संस्करण वा यसको व्युत्पन्न PWB थियो, जस्तो कि मैले विश्वास गरें।

मैले खोजलाई आधारको रूपमा लिएँ र छैटौं संस्करणमा म्यानुअल रूपमा स्रोतहरू सम्पादन गरें। केही कोडहरू उस्तै रह्यो, तर केहीलाई थोरै सम्पादन गर्नुपर्ने थियो, आधुनिक += टोकनलाई पुरानो =+ मा परिवर्तन गर्दै। केहि चीजहरू सजिलै मेटाइएका थिए, र केहि पूर्ण रूपमा पुन: लेख्नु परेको थियो, तर धेरै होइन।

र आज हामी TUHS मा छैटौं संस्करणको स्रोत कोड अनलाइन पढ्न सक्छौं अभिलेख, जसमा डेनिस रिचीको हात थियो.

वैसे, पहिलो नजर मा, केर्निघन र रिची को अवधि अघि C-कोड को मुख्य विशेषता यसको हो। संक्षिप्तता। यो प्रायः होइन कि म मेरो साइटमा अपेक्षाकृत साँघुरो प्रदर्शन क्षेत्र फिट गर्न व्यापक सम्पादन बिना कोडका टुक्राहरू सम्मिलित गर्न सक्षम छु।

सुरुमा /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 फाइलहरूको लागि, तिनीहरू अनुरूप छन् inode झण्डा 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;
}

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

साथ प्रयास गरौं ialloc() डिस्कमा राख्नुहोस् inode (सूचकांक ह्यान्डल), र सहयोग संग falloc() - मेमोरीमा दुई राख्नुहोस् फाइल। यदि सबै ठीक छ भने, हामी यी फाइलहरूलाई पाइपलाइनको दुई छेउको रूपमा पहिचान गर्न फ्ल्यागहरू सेट गर्नेछौं, तिनीहरूलाई एउटै आइनोडमा देखाउनेछौं (जसको सन्दर्भ गणना 2 मा सेट गरिने छ), र आइनोडलाई परिमार्जित र प्रयोगमा चिन्ह लगाउनुहोस्। अनुरोधहरूमा ध्यान दिनुहोस् iput() नयाँ inode मा सन्दर्भ गणना कम गर्न त्रुटि मार्गहरूमा।

pipe() मार्फत गर्नुपर्छ R0 и R1 पढ्न र लेख्नको लागि फाइल वर्णनकर्ता नम्बरहरू फर्काउनुहोस्। falloc() फाइल संरचनामा सूचक फर्काउँछ, तर मार्फत "फिर्ता" पनि गर्छ u.u_ar0[R0] र फाइल वर्णनकर्ता। त्यो हो, कोड भित्र बचत हुन्छ r पढ्नको लागि फाइल वर्णनकर्ता र सिधै लेख्नको लागि फाइल वर्णनकर्ता नियुक्त गर्दछ u.u_ar0[R0] दोस्रो कल पछि falloc().

फ्ल्याग FPIPE, जुन हामीले पाइपलाइन सिर्जना गर्दा सेट गर्छौं, प्रकार्यको व्यवहार नियन्त्रण गर्दछ rdwr() sys2.c माविशिष्ट 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).

त्यसपछि हामी inode सन्दर्भ काउन्टर जाँच गर्छौं। जबसम्म पाइपलाइनको दुवै छेउ खुला रहन्छ, काउन्टर 2 बराबर हुनुपर्छ। हामीले एउटा लिङ्क (बाट rp->f_inode), त्यसैले यदि काउन्टर २ भन्दा कम छ भने, यसको अर्थ पढ्ने प्रक्रियाले पाइपलाइनको अन्त्य बन्द गरेको हुनुपर्छ। अर्को शब्दमा, हामी बन्द पाइपलाइनमा लेख्ने प्रयास गर्दैछौं, र यो त्रुटि हो। पहिलो पटक त्रुटि कोड EPIPE र संकेत SIGPIPE युनिक्सको छैठौं संस्करणमा देखा पर्‍यो।

तर कन्वेयर खुला छ भने पनि, यो भरिएको हुन सक्छ। यस अवस्थामा, हामी लक छोड्छौं र अर्को प्रक्रियाले पाइपलाइनबाट पढ्नेछ र यसमा पर्याप्त ठाउँ खाली गर्नेछ भन्ने आशामा सुत्न जान्छौं। ब्यूँझिएपछि, हामी सुरुमा फर्कन्छौं, फेरि ताला झुण्ड्याउँछौं र नयाँ रेकर्डिङ चक्र सुरु गर्छौं।

यदि पाइपलाइनमा पर्याप्त खाली ठाउँ छ भने, हामी यसलाई प्रयोग गरेर डाटा लेख्छौं लेखी()... प्यारामिटर i_size1 inode (यदि पाइपलाइन खाली छ भने, यो 0 को बराबर हुन सक्छ) ले पहिले नै समावेश गरेको डेटाको अन्त्यलाई संकेत गर्दछ। यदि त्यहाँ पर्याप्त रेकर्डिङ ठाउँ छ भने, हामी पाइपलाइनबाट भर्न सक्छौं i_size1 गर्न PIPESIZ। त्यसपछि हामी लक छोड्छौं र पाइपलाइनबाट पढ्नको लागि पर्खिरहेको कुनै पनि प्रक्रियालाई जगाउने प्रयास गर्छौं। हामी सुरुमा फिर्ता जान्छौं कि हामीले चाहिने जति बाइटहरू लेख्न सक्षम थियौं। यदि यो असफल भयो भने, हामी नयाँ रेकर्डिङ चक्र सुरु गर्छौं।

सामान्यतया प्यारामिटर i_mode inode अनुमतिहरू भण्डारण गर्न प्रयोग गरिन्छ r, w и x। तर पाइपलाइनको अवस्थामा, हामी संकेत गर्छौं कि केही प्रक्रिया बिटहरू प्रयोग गरेर लेख्न वा पढ्नको लागि पर्खिरहेको छ IREAD и IWRITE क्रमशः। प्रक्रियाले झण्डा र कलहरू सेट गर्दछ sleep(), र यो आशा छ कि भविष्यमा केहि अन्य प्रक्रिया कारण हुनेछ wakeup().

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

/*
 * 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 inode मा। हामीले स्थितिलाई ० मा रिसेट गर्छौं र पाइपलाइनमा लेख्न चाहने कुनै पनि प्रक्रियालाई जगाउने प्रयास गर्छौं। हामीलाई थाहा छ जब कन्वेयर भरिन्छ, writep() मा सुत्नेछ ip+1। र अब जब पाइपलाइन खाली छ, हामी यसलाई यसको लेखन चक्र पुन: सुरु गर्न जगाउन सक्छौं।

यदि तपाइँसँग पढ्नको लागि केहि छैन भने, त्यसपछि readp() झण्डा सेट गर्न सक्छ IREAD र सुत्नुहोस् ip+2। हामीलाई थाहा छ उसलाई के जगाउनेछ writep(), जब यसले पाइपलाइनमा केही डेटा लेख्छ।

टिप्पणीहरू readi() र writei() " मार्फत प्यारामिटरहरू पास गर्नुको सट्टा बुझ्न मद्दत गर्नेछ।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() चक्र पुन: सुरु गर्छ।

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

Unix को सातौं संस्करण (जनवरी 1979) एक नयाँ प्रमुख रिलीज (चार वर्ष पछि) थियो जसले धेरै नयाँ अनुप्रयोगहरू र कर्नेल सुविधाहरू प्रस्तुत गर्‍यो। यसले टाइप कास्टिङ, युनियनहरू र संरचनाहरूमा टाइप गरिएका सूचकहरूको प्रयोगको सम्बन्धमा पनि महत्त्वपूर्ण परिवर्तनहरू पार गर्यो। यद्यपि कन्वेयर कोड व्यावहारिक रूपमा अपरिवर्तित। हामी यो संस्करण छोड्न सक्छौं।

Xv6, एक साधारण युनिक्स जस्तो कर्नेल

कर्नेल सिर्जना गर्न Xv6 युनिक्सको छैठौं संस्करणबाट प्रभावित, तर यो x86 प्रोसेसरहरूमा चलाउनको लागि आधुनिक C मा लेखिएको छ। कोड पढ्न र बुझ्न सजिलो छ। साथै, TUHS सँग युनिक्स स्रोतहरूको विपरीत, तपाईंले यसलाई कम्पाइल गर्न, परिमार्जन गर्न र PDP 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

लिनक्स ०.०१ स्रोत कोड फेला पार्न सकिन्छ। उहाँमा पाइपलाइनको कार्यान्वयन अध्ययन गर्न निर्देशनात्मक हुनेछ fs/pipe.c। यसले पाइपलाइनलाई प्रतिनिधित्व गर्नको लागि इनोड प्रयोग गर्दछ, तर पाइपलाइन आफैंमा आधुनिक C मा लेखिएको छ। यदि तपाईंले XNUMX औं संस्करणको कोड मार्फत आफ्नो तरिकाले काम गर्नुभयो भने, तपाईंलाई यहाँ कुनै समस्या हुनेछैन। यो प्रकार्य जस्तो देखिन्छ 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 त्यति विदेशी देखिदैन ।

आधुनिक लिनक्स कर्नेल, FreeBSD, NetBSD, OpenBSD

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

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

जे भए पनि, मलाई केहि पुराना ढाँचाहरू (जस्तै उत्पन्न गर्ने) खन्नमा रुचि थियो SIGPIPE र फिर्ता EPIPE बन्द पाइपलाइनमा लेख्दा) यी सबै फरक आधुनिक कर्नेलहरूमा। म सायद वास्तविक जीवनमा PDP-11 कम्प्यूटर कहिल्यै देख्दिन, तर मेरो जन्म हुनुभन्दा वर्षौं अघि लेखिएको कोडबाट सिक्न अझै धेरै छ।

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

स्रोत: www.habr.com