युनिक्समध्ये पाइपलाइन कशा लागू केल्या जातात

हा लेख युनिक्स कर्नलमधील पाइपलाइनच्या अंमलबजावणीचे वर्णन करतो. मी काहीसा निराश झालो की अलीकडील लेख "युनिक्समध्ये पाइपलाइन कसे कार्य करतात?"बाहेर पडले नाही अंतर्गत रचना बद्दल. मी उत्सुक झालो आणि उत्तर शोधण्यासाठी जुन्या स्त्रोतांचा शोध घेतला.

आम्ही कशाबद्दल बोलत आहोत?

पाइपलाइन, "कदाचित युनिक्समधील सर्वात महत्त्वाचा शोध," हे लहान प्रोग्राम्सना एकत्र जोडण्याच्या अंतर्निहित युनिक्स तत्त्वज्ञानाचे परिभाषित वैशिष्ट्य आहे, तसेच कमांड लाइनवरील एक परिचित चिन्ह आहे:

$ 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 शी जुळण्यासाठी descriptors 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), किंवा अपूर्ण स्त्रोत कोडमध्ये दुसरी आवृत्ती (जून १९७२).

टीयूएचएस म्हणते की युनिक्सची तिसरी आवृत्ती (फेब्रुवारी 1973) कन्व्हेयर्ससह पहिली आवृत्ती बनली:

युनिक्स 1973री आवृत्ती विधानसभा भाषेत लिहिलेली कर्नल असलेली शेवटची आवृत्ती होती, परंतु पाइपलाइनसह पहिली आवृत्ती देखील होती. XNUMX च्या दरम्यान, तिसरी आवृत्ती सुधारण्यासाठी कार्य केले गेले, कर्नल C मध्ये पुन्हा लिहिला गेला आणि म्हणून युनिक्सची चौथी आवृत्ती आली.

एका वाचकाला एका दस्तऐवजाचे स्कॅन सापडले ज्यामध्ये डग मॅकिलरॉयने "गार्डन होजसारखे प्रोग्राम कनेक्ट करणे" ची कल्पना मांडली.

ब्रायन कर्निघन यांच्या पुस्तकातयुनिक्स: एक इतिहास आणि एक संस्मरण", कन्व्हेयर्सच्या उदयाच्या इतिहासात, या दस्तऐवजाचा देखील उल्लेख आहे: "... ते माझ्या बेल लॅबमधील कार्यालयात 30 वर्षांपासून भिंतीवर लटकले होते." येथे McIlroy सह मुलाखत, आणि कडून दुसरी कथा मॅक्इलरॉयचे कार्य, 2014 मध्ये लिहिलेले:

जेव्हा युनिक्स बाहेर आले, तेव्हा माझ्या कॉरोटीनबद्दलच्या आकर्षणामुळे मला OS चे लेखक, केन थॉम्पसन यांना एका प्रक्रियेवर लिहिलेला डेटा केवळ डिव्हाइसवरच नाही तर दुसऱ्या प्रक्रियेसाठी आउटपुट करण्यासाठी देखील विचारले. केनने ठरवले की हे शक्य आहे. तथापि, मिनिमलिस्ट म्हणून, प्रत्येक सिस्टम फंक्शनने महत्त्वपूर्ण भूमिका बजावावी अशी त्यांची इच्छा होती. इंटरमीडिएट फाइलवर लिहिण्यापेक्षा प्रक्रियांमध्ये थेट लिहिणे हा खरोखरच मोठा फायदा आहे का? जेव्हा मी आकर्षक नाव "पाइपलाइन" आणि प्रक्रियांमधील परस्परसंवादासाठी वाक्यरचनाचे वर्णन असलेला एक विशिष्ट प्रस्ताव ठेवला तेव्हाच केनने शेवटी उद्गार काढले: "मी ते करेन!"

आणि केले. एका भयंकर संध्याकाळी, केनने कर्नल आणि शेल बदलले, त्यांनी इनपुट कसे स्वीकारले (जे पाइपलाइनमधून येऊ शकते) प्रमाणित करण्यासाठी अनेक मानक प्रोग्राम निश्चित केले आणि फाइलची नावे देखील बदलली. दुसऱ्या दिवशी, पाईपलाईन अनुप्रयोगांमध्ये मोठ्या प्रमाणात वापरल्या जाऊ लागल्या. आठवड्याच्या अखेरीस, सचिव वर्ड प्रोसेसरवरून प्रिंटरवर कागदपत्रे पाठवण्यासाठी त्यांचा वापर करत होते. थोड्या वेळाने, केनने मूळ API आणि वाक्यरचना क्लीनर कन्व्हेन्शन्ससह पाइपलाइनचा वापर गुंडाळण्यासाठी बदलली, जी तेव्हापासून वापरली जात आहे.

दुर्दैवाने, युनिक्स कर्नलच्या तिसऱ्या आवृत्तीचा स्त्रोत कोड गमावला आहे. आणि जरी आमच्याकडे कर्नल सोर्स कोड C मध्ये लिहिलेला आहे चौथी आवृत्ती, नोव्हेंबर 1973 मध्ये रिलीझ झाले, परंतु ते अधिकृत प्रकाशनाच्या कित्येक महिने आधी आले आणि त्यात पाइपलाइन अंमलबजावणी समाविष्ट नाही. या पौराणिक युनिक्स फंक्शनचा स्त्रोत कोड कदाचित कायमचा गमावला ही लाजिरवाणी गोष्ट आहे.

आमच्याकडे मजकूर दस्तऐवजीकरण आहे pipe(2) दोन्ही रिलीझमधून, जेणेकरून तुम्ही दस्तऐवज शोधून प्रारंभ करू शकता तिसरी आवृत्ती (काही शब्दांसाठी, अधोरेखित “मॅन्युअली”, अक्षरांची एक स्ट्रिंग ^H, त्यानंतर अंडरस्कोर!). हा प्रोटो-pipe(2) असेंबली भाषेत लिहिलेले आहे आणि फक्त एक फाइल वर्णनकर्ता परत करते, परंतु आधीच अपेक्षित कोर कार्यक्षमता प्रदान करते:

सिस्टम कॉल पाईप पाइपलाइन नावाची इनपुट/आउटपुट यंत्रणा तयार करते. रिटर्न केलेल्या फाइल डिस्क्रिप्टरचा वापर वाचन आणि लेखन ऑपरेशन्ससाठी केला जाऊ शकतो. जेव्हा पाइपलाइनवर काहीतरी लिहिले जाते, तेव्हा 504 बाइट्सपर्यंत डेटा बफर केला जातो, त्यानंतर लेखन प्रक्रिया निलंबित केली जाते. पाइपलाइनमधून वाचताना, बफर केलेला डेटा काढून घेतला जातो.

पुढील वर्षी कर्नल C मध्ये पुन्हा लिहिला गेला होता, आणि पाईप(2) चौथ्या आवृत्तीत प्रोटोटाइपसह त्याचे आधुनिक स्वरूप प्राप्त केले "pipe(fildes)"

सिस्टम कॉल पाईप पाइपलाइन नावाची इनपुट/आउटपुट यंत्रणा तयार करते. रिटर्न केलेल्या फाइलचे वर्णन वाचन आणि लेखन ऑपरेशन्समध्ये वापरले जाऊ शकते. जेव्हा पाइपलाइनवर काहीतरी लिहिले जाते, तेव्हा r1 (resp. fildes[1]) मध्ये परत आलेले हँडल वापरले जाते, डेटाच्या 4096 बाइट्सवर बफर केले जाते, त्यानंतर लेखन प्रक्रिया निलंबित केली जाते. पाइपलाइनमधून वाचताना, r0 (resp. fildes[0]) वर परत आलेले हँडल डेटा घेते.

असे गृहीत धरले जाते की एकदा पाइपलाइन परिभाषित केल्यानंतर, दोन (किंवा अधिक) संप्रेषण प्रक्रिया (त्यानंतरच्या कॉलद्वारे तयार केल्या जातात. काटा) कॉल वापरून पाइपलाइनमधून डेटा हस्तांतरित करेल वाचा и लिहू.

शेलमध्ये पाइपलाइनद्वारे जोडलेल्या प्रक्रियांच्या रेषीय ॲरे परिभाषित करण्यासाठी एक वाक्यरचना आहे.

रिकाम्या पाइपलाइनमधून (कोणताही बफर केलेला डेटा नसलेल्या) वाचण्यासाठी कॉल ज्यात फक्त एक टोक आहे (सर्व लेखन फाइल वर्णन करणारे बंद आहेत) "फाइलचा शेवट" परत करतात. तत्सम परिस्थितीत लिहिण्यासाठी कॉल दुर्लक्षित केले जातात.

लवकरात लवकर संरक्षित पाइपलाइन अंमलबजावणी संदर्भित युनिक्सच्या पाचव्या आवृत्तीत (जून 1974), परंतु पुढील रिलीझमध्ये दिसलेल्या एकसारखेच आहे. टिप्पण्या नुकत्याच जोडल्या गेल्या आहेत, त्यामुळे तुम्ही पाचवी आवृत्ती वगळू शकता.

युनिक्सची सहावी आवृत्ती (1975)

चला युनिक्स सोर्स कोड वाचायला सुरुवात करूया सहावी आवृत्ती (मे 1975). यांचे मोठ्या प्रमाणावर आभार लायन्स पूर्वीच्या आवृत्त्यांच्या स्त्रोतांपेक्षा ते शोधणे खूप सोपे आहे:

अनेक वर्षांपासून पुस्तक लायन्स युनिक्स कर्नलवर बेल लॅबच्या बाहेर उपलब्ध असलेला एकमेव दस्तऐवज होता. सहाव्या आवृत्तीच्या परवान्याने शिक्षकांना त्याचा स्त्रोत कोड वापरण्याची परवानगी दिली असली तरी, सातव्या आवृत्तीच्या परवान्याने ही शक्यता वगळली, त्यामुळे पुस्तक बेकायदेशीर टंकलेखन प्रतींच्या स्वरूपात वितरित केले गेले.

आज तुम्ही पुस्तकाचे पुनर्मुद्रण खरेदी करू शकता, ज्याचे मुखपृष्ठ विद्यार्थ्यांना कॉपी मशीनवर दाखवते. आणि वॉरेन टूमीचे आभार (ज्याने TUHS प्रकल्प सुरू केला) आपण डाउनलोड करू शकता सहाव्या आवृत्तीसाठी स्त्रोत कोड असलेली PDF फाइल. फाइल तयार करण्यासाठी किती प्रयत्न केले गेले याची मला कल्पना द्यायची आहे:

15 वर्षांहून अधिक वर्षांपूर्वी, मी दिलेल्या स्त्रोत कोडची एक प्रत टाइप केली होती लायन्स, कारण मला इतर प्रतींच्या अज्ञात संख्येतील माझ्या प्रतीची गुणवत्ता आवडली नाही. TUHS अद्याप अस्तित्वात नव्हते आणि मला जुन्या स्त्रोतांमध्ये प्रवेश नव्हता. पण 1988 मध्ये, मला एक जुनी 9-ट्रॅक टेप सापडली ज्यामध्ये PDP11 संगणकाचा बॅकअप होता. ते काम करत आहे की नाही हे सांगणे कठिण होते, परंतु एक अखंड /usr/src/ झाड होते ज्यामध्ये बहुतेक फाईल्स 1979 चे लेबल होते, जे तेव्हाही प्राचीन दिसत होते. ती सातवी आवृत्ती होती किंवा तिचा व्युत्पन्न PWB होता, माझ्या विश्वासानुसार.

मी शोध एक आधार म्हणून घेतला आणि सहाव्या आवृत्तीसाठी स्त्रोत व्यक्तिचलितपणे संपादित केले. काही कोड सारखेच राहिले, परंतु काहींना थोडेसे संपादित करावे लागले, आधुनिक += टोकन कालबाह्य =+ मध्ये बदलून. काही गोष्टी फक्त हटवल्या गेल्या, आणि काही पूर्णपणे पुन्हा लिहिल्या गेल्या, पण जास्त नाही.

आणि आज आपण TUHS वर सहाव्या आवृत्तीचा स्त्रोत कोड ऑनलाइन वाचू शकतो संग्रहण, ज्यामध्ये डेनिस रिचीचा हात होता.

तसे, पहिल्या दृष्टीक्षेपात, कर्निघन आणि रिचीच्या कालावधीपूर्वी सी-कोडचे मुख्य वैशिष्ट्य म्हणजे त्याचे संक्षिप्तता. माझ्या साइटवर तुलनेने अरुंद डिस्प्ले क्षेत्र बसवण्यासाठी मी विस्तृत संपादनाशिवाय कोडचे तुकडे घालू शकत नाही असे सहसा घडत नाही.

सुरुवातीला /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 फाइल्ससाठी, ते संबंधित आहेत इनोड ध्वज मोठा, जी प्रक्रिया करण्यासाठी "मोठ्या ॲड्रेसिंग अल्गोरिदम" द्वारे वापरली जाते अप्रत्यक्ष ब्लॉक्स मोठ्या फाइल सिस्टमला समर्थन देण्यासाठी. त्यांचा वापर न करणे चांगले आहे असे केनने म्हटल्यामुळे, मी आनंदाने त्याचा शब्द स्वीकारतो.

येथे वास्तविक सिस्टम कॉल आहे 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 वर सेट केली जाईल), आणि आयनोडला सुधारित आणि वापरात आहे म्हणून चिन्हांकित करू. च्या विनंतीकडे लक्ष द्या मी ठेवले() नवीन इनोडमधील संदर्भ संख्या कमी करण्यासाठी त्रुटी मार्गांमध्ये.

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 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 येथे. आम्ही स्थिती 0 वर रीसेट करतो आणि पाइपलाइनवर लिहू इच्छित असलेल्या कोणत्याही प्रक्रियेस जागृत करण्याचा प्रयत्न करतो. आम्हाला माहित आहे की जेव्हा कन्व्हेयर भरलेला असतो, 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() सायकल पुन्हा सुरू करते.

हे सहाव्या आवृत्तीत कन्व्हेयर्सचे वर्णन पूर्ण करते. साधे कोड, दूरगामी परिणाम.

युनिक्सची सातवी आवृत्ती (जानेवारी 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

लिनक्स 0.01 स्त्रोत कोड आढळू शकतो. त्याच्यामध्ये पाइपलाइनच्या अंमलबजावणीचा अभ्यास करणे बोधप्रद असेल fs/pipe.c. हे पाइपलाइनचे प्रतिनिधित्व करण्यासाठी एक inode वापरते, परंतु पाइपलाइन स्वतः आधुनिक C मध्ये लिहिलेली आहे. जर तुम्ही 6 व्या आवृत्तीच्या कोडद्वारे काम केले असेल, तर तुम्हाला येथे कोणताही त्रास होणार नाही. फंक्शन असे दिसते 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 (*BSD वर), यासाठी खरे समर्पण लागते. आजचा कोड वेक्टर आणि असिंक्रोनस I/O सारख्या वैशिष्ट्यांसाठी कार्यप्रदर्शन आणि समर्थन याबद्दल आहे. आणि मेमरी वाटप, लॉक आणि कर्नल कॉन्फिगरेशनचे तपशील मोठ्या प्रमाणात बदलतात. प्रास्ताविक ऑपरेटिंग सिस्टम कोर्ससाठी महाविद्यालयांना याची आवश्यकता नाही.

असो, मला काही जुने नमुने शोधण्यात रस होता (जसे की निर्माण करणे SIGPIPE आणि परत EPIPE बंद पाइपलाइनवर लिहिताना) या सर्व भिन्न आधुनिक कर्नलमध्ये. मी कदाचित वास्तविक जीवनात PDP-11 संगणक कधीच पाहणार नाही, परंतु माझ्या जन्माच्या काही वर्षांपूर्वी लिहिलेल्या कोडमधून शिकण्यासारखे बरेच काही आहे.

2011 मध्ये दिवी कपूर यांनी लिहिलेला लेख:पाईप्स आणि FIFOs ची लिनक्स कर्नल अंमलबजावणी" Linux मध्ये पाइपलाइन (अजूनही) कसे कार्य करतात याचे विहंगावलोकन प्रदान करते. ए लिनक्स मध्ये अलीकडील कमिट परस्परसंवादाचे पाइपलाइन मॉडेल दर्शवते, ज्याची क्षमता तात्पुरत्या फाइल्सपेक्षा जास्त आहे; आणि युनिक्स कर्नलच्या सहाव्या आवृत्तीच्या "अत्यंत पुराणमतवादी लॉकिंग" पासून पाइपलाइन किती दूर आल्या आहेत हे देखील दर्शविते.

स्त्रोत: www.habr.com