இந்த கட்டுரை யூனிக்ஸ் கர்னலில் பைப்லைன்களை செயல்படுத்துவதை விவரிக்கிறது. " என்ற தலைப்பில் சமீபத்தில் வந்த கட்டுரையால் நான் சற்று ஏமாற்றமடைந்தேன்.» மாறியது இல்லை உள் அமைப்பு பற்றி. நான் ஆர்வமாகி, பதிலைக் கண்டுபிடிக்க பழைய ஆதாரங்களைத் தோண்டினேன்.
நாம் என்ன பேசுகிறோம்?
பைப்லைன்கள் "யூனிக்ஸ் இல் மிக முக்கியமான கண்டுபிடிப்பு" - யூனிக்ஸ் சிறிய நிரல்களை ஒன்றாக இணைக்கும் அடிப்படை தத்துவத்தின் வரையறுக்கும் பண்பு, அத்துடன் கட்டளை வரியில் உள்ள நன்கு அறியப்பட்ட கல்வெட்டு:
$ 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) அணுவாக இருக்க வேண்டும், இதனால் செயல்முறைகள் பைப்லைன் மூலம் ஒருவரையொருவர் தொடர்பு கொள்ள முடியும், சாதாரண கோப்புகள் (அவை அத்தகைய உத்தரவாதங்களை வழங்காது).
ஒரு வழக்கமான கோப்புடன், ஒரு செயல்முறை அதன் அனைத்து வெளியீட்டையும் எழுதி மற்றொரு செயல்முறைக்கு அனுப்ப முடியும். அல்லது செயல்முறைகள் கடினமான இணையான பயன்முறையில் செயல்படலாம், ஒரு வெளிப்புற சமிக்ஞை பொறிமுறையைப் பயன்படுத்தி (செமாஃபோர் போன்றவை) ஒரு எழுதுதல் அல்லது வாசிப்பை முடித்ததைப் பற்றி ஒருவருக்கொருவர் தெரிவிக்கலாம். கன்வேயர்கள் இந்த தொந்தரவுகளிலிருந்து நம்மைக் காப்பாற்றுகின்றன.
நாம் என்ன தேடுகிறோம்?
ஒரு கன்வேயர் எவ்வாறு வேலை செய்ய முடியும் என்பதை நீங்கள் கற்பனை செய்வதை எளிதாக்குவதற்கு நான் என் விரல்களில் விளக்குகிறேன். நீங்கள் ஒரு இடையகத்தையும் நினைவகத்தில் சில நிலையையும் ஒதுக்க வேண்டும். இடையகத்திலிருந்து தரவைச் சேர்க்க மற்றும் அகற்ற உங்களுக்கு செயல்பாடுகள் தேவைப்படும். கோப்பு விளக்கங்களில் படிக்க மற்றும் எழுதும் செயல்பாடுகளின் போது செயல்பாடுகளை அழைக்க உங்களுக்கு சில வசதிகள் தேவைப்படும். மேலே விவரிக்கப்பட்ட சிறப்பு நடத்தை செயல்படுத்த பூட்டுகள் தேவை.
எங்கள் தெளிவற்ற மன மாதிரியை உறுதிப்படுத்த அல்லது நிராகரிக்க, பிரகாசமான விளக்கு வெளிச்சத்தின் கீழ் கர்னலின் மூலக் குறியீட்டை விசாரிக்க நாங்கள் இப்போது தயாராக உள்ளோம். ஆனால் எதிர்பாராத நிகழ்வுகளுக்கு எப்போதும் தயாராக இருங்கள்.
எங்கே தேடுகிறோம்?
புகழ்பெற்ற புத்தகத்தின் எனது நகல் எங்கே இருக்கிறது என்று எனக்குத் தெரியவில்லை.« Unix 6 மூலக் குறியீட்டுடன், ஆனால் நன்றி ஆன்லைனில் தேடலாம் Unix இன் பழைய பதிப்புகளும் கூட.
TUHS காப்பகங்கள் வழியாக அலைவது ஒரு அருங்காட்சியகத்தைப் பார்ப்பது போன்றது. எங்களின் பகிரப்பட்ட வரலாற்றை நாம் பார்க்கலாம், பழைய கேசட்டுகள் மற்றும் அச்சுப் பிரதிகளில் இருந்து கொஞ்சம் கொஞ்சமாக இந்தப் பொருள் அனைத்தையும் மீட்டெடுப்பதற்கான பல வருட முயற்சிகளுக்கு நான் மரியாதை உண்டு. இன்னும் காணாமல் போன அந்த துண்டுகளை நான் நன்கு அறிவேன்.
பைப்லைன்களின் பழங்கால வரலாற்றைப் பற்றிய நமது ஆர்வத்தைத் திருப்திப்படுத்தியதால், ஒப்பிடுவதற்கு நவீன கோர்களை நாம் பார்க்கலாம்.
மூலம், pipe அட்டவணையில் கணினி அழைப்பு எண் 42 ஆகும் sysent[]. தற்செயலா?
பாரம்பரிய யூனிக்ஸ் கர்னல்கள் (1970–1974)
நான் எந்த தடயத்தையும் காணவில்லை pipe(2) உள்ளேயும் இல்லை (ஜனவரி 1970), அல்லது இல்லை (நவம்பர் 1971), அல்லது முழுமையற்ற மூலக் குறியீட்டில் இல்லை (ஜூன் 1972).
TUHS கூறுகிறது (பிப்ரவரி 1973) பைப்லைன்கள் கொண்ட முதல் பதிப்பு:
Unix இன் மூன்றாவது பதிப்பு அசெம்பிளரில் எழுதப்பட்ட கர்னலுடன் கடைசிப் பதிப்பாகும், ஆனால் பைப்லைன்களுடன் கூடிய முதல் பதிப்பாகும். 1973 ஆம் ஆண்டில், மூன்றாவது பதிப்பை மேம்படுத்துவதற்கான பணிகள் நடந்து கொண்டிருந்தன, கர்னல் C இல் மீண்டும் எழுதப்பட்டது, இதனால் யூனிக்ஸ் நான்காவது பதிப்பு பிறந்தது.
ஒரு வாசகர் ஒரு ஆவணத்தை ஸ்கேன் செய்தார், அதில் டக் மெக்ல்ராய் "ஒரு தோட்டக் குழாய் போன்ற நிரல்களை இணைக்கும்" யோசனையை முன்மொழிந்தார்.
பிரையன் கெர்னிகனின் புத்தகத்தில்", கன்வேயர்களின் தோற்றத்தின் வரலாறு இந்த ஆவணத்தையும் குறிப்பிடுகிறது: "... இது 30 ஆண்டுகளாக பெல் லேப்ஸில் உள்ள எனது அலுவலகத்தில் சுவரில் தொங்கியது." இங்கே மற்றும் மற்றொரு கதை :
Unix தோன்றிய போது, coroutines மீதான எனது ஆர்வம், OS ஆசிரியரான கென் தாம்சனிடம், சில செயல்முறைகளில் எழுதப்பட்ட தரவை சாதனத்திற்கு மட்டுமல்ல, மற்றொரு செயல்முறைக்கும் செல்ல அனுமதிக்குமாறு என்னைக் கேட்க வைத்தது. அது சாத்தியம் என்று கென் நினைத்தார். இருப்பினும், ஒரு மினிமலிஸ்டாக, ஒவ்வொரு கணினி அம்சமும் குறிப்பிடத்தக்க பங்கைக் கொண்டிருக்க வேண்டும் என்று அவர் விரும்பினார். ஒரு இடைநிலை கோப்பில் எழுதுவதை விட செயல்முறைகளுக்கு இடையில் நேரடியாக எழுதுவது உண்மையில் ஒரு பெரிய நன்மையா? "பைப்லைன்" என்ற கவர்ச்சியான பெயர் மற்றும் செயல்முறைகளின் தொடர்புகளின் தொடரியல் பற்றிய விளக்கத்துடன் நான் ஒரு குறிப்பிட்ட முன்மொழிவைச் செய்தபோதுதான், கென் இறுதியாக கூச்சலிட்டார்: "நான் அதை செய்வேன்!".
மற்றும் செய்தார். ஒரு அதிர்ஷ்டமான மாலை, கென் கர்னல் மற்றும் ஷெல்லை மாற்றினார், அவர்கள் உள்ளீட்டை எவ்வாறு ஏற்றுக்கொள்கிறார்கள் என்பதைத் தரநிலைப்படுத்த பல நிலையான நிரல்களை சரிசெய்தார் (இது ஒரு பைப்லைனில் இருந்து வரலாம்) மற்றும் கோப்பு பெயர்களை மாற்றினார். அடுத்த நாள், குழாய்கள் பயன்பாடுகளில் மிகவும் பரவலாகப் பயன்படுத்தப்பட்டன. வார இறுதிக்குள், செயலாளர்கள் அவற்றைப் பயன்படுத்தி வேர்ட் பிராசஸர்களில் இருந்து அச்சுப்பொறிக்கு ஆவணங்களை அனுப்பினார்கள். சிறிது நேரம் கழித்து, கென் அசல் ஏபிஐ மற்றும் தொடரியல் ஆகியவற்றை மாற்றியமைத்தார், பைப்லைன்களின் பயன்பாட்டை அன்றிலிருந்து பயன்படுத்தப்பட்டு வரும் தூய்மையான மரபுகளுடன்.
துரதிர்ஷ்டவசமாக, யூனிக்ஸ் கர்னலின் மூன்றாம் பதிப்புக்கான மூலக் குறியீடு தொலைந்து விட்டது. எங்களிடம் கர்னல் மூல குறியீடு C இல் எழுதப்பட்டிருந்தாலும் , இது நவம்பர் 1973 இல் வெளியிடப்பட்டது, ஆனால் அது அதிகாரப்பூர்வ வெளியீட்டிற்கு சில மாதங்களுக்கு முன்பு வெளிவந்தது மற்றும் குழாய்களை செயல்படுத்துவதைக் கொண்டிருக்கவில்லை. இந்த புகழ்பெற்ற யுனிக்ஸ் அம்சத்திற்கான மூலக் குறியீடு தொலைந்து போனது வருத்தம் அளிக்கிறது, ஒருவேளை என்றென்றும் இருக்கலாம்.
எங்களிடம் ஆவண உரை உள்ளது pipe(2) இரண்டு வெளியீடுகளிலிருந்தும், ஆவணங்களைத் தேடுவதன் மூலம் நீங்கள் தொடங்கலாம் (சில வார்த்தைகளுக்கு, "கைமுறையாக" அடிக்கோடிட்டு, ^H லிட்டரல்களின் சரம், அதைத் தொடர்ந்து அடிக்கோடிடும்!). இந்த புரோட்டோ-pipe(2) அசெம்பிளரில் எழுதப்பட்டது மற்றும் ஒரே ஒரு கோப்பு விளக்கத்தை மட்டுமே வழங்குகிறது, ஆனால் ஏற்கனவே எதிர்பார்க்கப்படும் முக்கிய செயல்பாட்டை வழங்குகிறது:
கணினி அழைப்பு குழாய் பைப்லைன் எனப்படும் I/O பொறிமுறையை உருவாக்குகிறது. திரும்பிய கோப்பு விளக்கத்தை படிக்க மற்றும் எழுதும் செயல்பாடுகளுக்கு பயன்படுத்தலாம். பைப்லைனில் ஏதாவது எழுதப்பட்டால், அது 504 பைட்டுகள் வரை டேட்டாவைத் தாங்குகிறது, அதன் பிறகு எழுதும் செயல்முறை இடைநிறுத்தப்படும். பைப்லைனில் இருந்து படிக்கும் போது, இடையக தரவு எடுக்கப்படுகிறது.
அடுத்த ஆண்டு, கர்னல் C இல் மீண்டும் எழுதப்பட்டது, மற்றும் முன்மாதிரியுடன் அதன் நவீன தோற்றத்தைப் பெற்றது "pipe(fildes)»:
கணினி அழைப்பு குழாய் பைப்லைன் எனப்படும் I/O பொறிமுறையை உருவாக்குகிறது. திரும்பிய கோப்பு விளக்கங்கள் படிக்க மற்றும் எழுதும் செயல்பாடுகளில் பயன்படுத்தப்படலாம். பைப்லைனில் ஏதாவது எழுதப்பட்டால், r1 (resp. fildes[1]) இல் திரும்பிய விவரிப்பான் பயன்படுத்தப்படுகிறது, 4096 பைட்டுகள் தரவு வரை இடையீடு செய்யப்படுகிறது, அதன் பிறகு எழுதும் செயல்முறை இடைநிறுத்தப்படும். பைப்லைனில் இருந்து படிக்கும் போது, டிஸ்கிரிப்டர் r0க்கு திரும்பியது (resp. fildes[0]) தரவை எடுக்கிறது.
ஒரு குழாய் வரையறுக்கப்பட்டவுடன், இரண்டு (அல்லது அதற்கு மேற்பட்ட) ஊடாடும் செயல்முறைகள் (அடுத்தடுத்த அழைப்புகளால் உருவாக்கப்பட்டது. போர்க்) அழைப்புகளைப் பயன்படுத்தி பைப்லைனிலிருந்து தரவை அனுப்பும் படிக்க и எழுத.
ஒரு குழாய் வழியாக இணைக்கப்பட்ட செயல்முறைகளின் நேரியல் வரிசையை வரையறுக்க ஷெல் ஒரு தொடரியல் உள்ளது.
ஒரே ஒரு முனையைக் கொண்ட (அனைத்து எழுதும் கோப்பு விளக்கங்களும் மூடப்பட்டன) காலியான பைப்லைனில் இருந்து படிக்க அழைப்புகள் "கோப்பின் முடிவு" திரும்பும். இதேபோன்ற சூழ்நிலையில் எழுதும் அழைப்புகள் புறக்கணிக்கப்படும்.
ஆரம்பமானது பொருந்தும் (ஜூன் 1974), ஆனால் இது அடுத்த வெளியீட்டில் தோன்றியதைப் போலவே உள்ளது. கருத்துகள் மட்டும் சேர்க்கப்பட்டதால், ஐந்தாவது பதிப்பைத் தவிர்க்கலாம்.
யூனிக்ஸ் ஆறாவது பதிப்பு (1975)
யூனிக்ஸ் மூலக் குறியீட்டைப் படிக்கத் தொடங்குகிறது (மே 1975). பெரிதும் நன்றி லயன்ஸ் முந்தைய பதிப்புகளின் ஆதாரங்களைக் காட்டிலும் கண்டுபிடிப்பது மிகவும் எளிதானது:
பல ஆண்டுகளாக புத்தகம் லயன்ஸ் பெல் லேப்ஸுக்கு வெளியே யுனிக்ஸ் கர்னலில் உள்ள ஒரே ஆவணம். ஆறாவது பதிப்பு உரிமம் ஆசிரியர்கள் அதன் மூலக் குறியீட்டைப் பயன்படுத்த அனுமதித்தாலும், ஏழாவது பதிப்பு உரிமம் இந்த வாய்ப்பை விலக்கியது, எனவே புத்தகம் சட்டவிரோதமாக தட்டச்சு செய்யப்பட்ட பிரதிகளில் விநியோகிக்கப்பட்டது.
இன்று நீங்கள் புத்தகத்தின் மறுபதிப்பு நகலை வாங்கலாம், அதன் அட்டையானது நகலெடுக்கும் இயந்திரத்தில் மாணவர்களை சித்தரிக்கிறது. வாரன் டூமிக்கு நன்றி (TUHS திட்டத்தைத் தொடங்கியவர்), நீங்கள் பதிவிறக்கலாம் . கோப்பை உருவாக்க எவ்வளவு முயற்சி எடுக்கப்பட்டது என்பதை நான் உங்களுக்குத் தெரிவிக்க விரும்புகிறேன்:
15 ஆண்டுகளுக்கு முன்பு, வழங்கப்பட்ட மூலக் குறியீட்டின் நகலை நான் தட்டச்சு செய்தேன் லயன்ஸ்ஏனெனில் அறியப்படாத பிற பிரதிகளில் இருந்து எனது பிரதியின் தரம் எனக்குப் பிடிக்கவில்லை. TUHS இன்னும் இல்லை, மேலும் பழைய ஆதாரங்களுக்கான அணுகல் என்னிடம் இல்லை. ஆனால் 1988 ஆம் ஆண்டில், PDP9 கணினியிலிருந்து காப்புப் பிரதி எடுக்கப்பட்ட 11 தடங்கள் கொண்ட பழைய டேப்பைக் கண்டேன். இது செயல்படுகிறதா என்று தெரிந்து கொள்வது கடினமாக இருந்தது, ஆனால் ஒரு அப்படியே /usr/src/ மரம் இருந்தது, அதில் பெரும்பாலான கோப்புகள் 1979 என்று குறிக்கப்பட்டன, அது கூட பழமையானதாக இருந்தது. இது ஏழாவது பதிப்பு அல்லது PWB வழித்தோன்றல் என்று நான் நினைத்தேன்.
நான் கண்டறிதலை அடிப்படையாக எடுத்துக்கொண்டு, ஆறாவது பதிப்பின் நிலைக்கு ஆதாரங்களை கைமுறையாகத் திருத்தினேன். குறியீட்டின் ஒரு பகுதி அப்படியே இருந்தது, பகுதி சிறிது திருத்தப்பட வேண்டும், நவீன டோக்கனை += வழக்கற்று =+ ஆக மாற்ற வேண்டும். ஏதோ வெறுமனே நீக்கப்பட்டது, மேலும் எதையாவது முழுமையாக மீண்டும் எழுத வேண்டும், ஆனால் அதிகமாக இல்லை.
இன்று ஆறாவது பதிப்பின் மூலக் குறியீட்டை TUHS இல் ஆன்லைனில் படிக்கலாம் .
மூலம், முதல் பார்வையில், கெர்னிகன் மற்றும் ரிச்சியின் காலத்திற்கு முந்தைய சி-குறியீட்டின் முக்கிய அம்சம் சுருக்கம். எனது தளத்தில் ஒப்பீட்டளவில் குறுகிய காட்சிப் பகுதிக்கு ஏற்றவாறு, விரிவான எடிட்டிங் இல்லாமல் குறியீட்டின் துணுக்குகளைச் செருகுவது பெரும்பாலும் இல்லை.
ஆரம்பத்தில் ஒரு விளக்கக் கருத்து உள்ளது (ஆம், இன்னும் உள்ளது ):
/*
* 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
நான்காவது பதிப்பிலிருந்து இடையக அளவு மாறவில்லை. ஆனால் இங்கே நாம் பார்க்கிறோம், எந்த பொது ஆவணங்களும் இல்லாமல், பைப்லைன்கள் ஒருமுறை கோப்புகளை ஃபால்பேக் சேமிப்பகமாக பயன்படுத்தியது!
பெரிய கோப்புகளைப் பொறுத்தவரை, அவை ஒத்திருக்கும் , இது "பெரிய முகவரியிடல் அல்காரிதம்" மூலம் செயலாக்க பயன்படுத்தப்படுகிறது பெரிய கோப்பு முறைமைகளை ஆதரிக்க. அவற்றைப் பயன்படுத்தாமல் இருப்பது நல்லது என்று கென் கூறியதால், அவருடைய வார்த்தையை ஏற்றுக் கொள்வதில் மகிழ்ச்சி அடைகிறேன்.
உண்மையான கணினி அழைப்பு இங்கே 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 கணினி அழைப்பு அளவுருக்கள் மற்றும் திரும்ப மதிப்புகள் அனுப்பப்பட்டன.
உடன் முயற்சி செய்யலாம் வட்டில் வைக்கவும் , மற்றும் உதவியுடன் - இரண்டு சேமிக்கவும் . எல்லாம் சரியாக நடந்தால், இந்தக் கோப்புகளை பைப்லைனின் இரு முனைகளாக அடையாளம் காண கொடிகளை அமைப்போம், அவற்றை ஒரே ஐனோடில் சுட்டிக்காட்டுவோம் (இதன் குறிப்பு எண்ணிக்கை 2 ஆகும்), மேலும் ஐனோடை மாற்றியமைத்து பயன்பாட்டில் உள்ளதாகக் குறிப்போம். கோரிக்கைகளுக்கு கவனம் செலுத்துங்கள் புதிய ஐனோடில் குறிப்பு எண்ணிக்கையை குறைப்பதற்கான பிழை பாதைகளில்.
pipe() மூலம் செலுத்த வேண்டும் R0 и R1 படிப்பதற்கும் எழுதுவதற்கும் கோப்பு விளக்க எண்களை திருப்பி அனுப்பவும். falloc() ஒரு கோப்பு கட்டமைப்பிற்கு ஒரு சுட்டியை திருப்பி அனுப்புகிறது, ஆனால் வழியாக "திரும்புகிறது" u.u_ar0[R0] மற்றும் ஒரு கோப்பு விளக்கம். அதாவது, குறியீடு சேமிக்கப்படுகிறது r படிப்பதற்கு கோப்பு விளக்கி மற்றும் நேரடியாக எழுதுவதற்கு ஒரு விளக்கத்தை ஒதுக்குகிறது u.u_ar0[R0] இரண்டாவது அழைப்புக்குப் பிறகு falloc().
கொடியை FPIPE, பைப்லைனை உருவாக்கும் போது நாம் அமைக்கும், செயல்பாட்டின் நடத்தையை கட்டுப்படுத்துகிறது , இது குறிப்பிட்ட 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'a (வெற்று பைப்லைனுடன் அது 0 க்கு சமமாக இருக்கலாம்) ஏற்கனவே உள்ள தரவின் முடிவைக் குறிக்கிறது. எழுதுவதற்கு போதுமான இடம் இருந்தால், பைப்லைனை நிரப்பலாம் i_size1 செய்ய PIPESIZ. பின்னர் நாங்கள் பூட்டை விடுவித்து, பைப்லைனில் இருந்து படிக்க காத்திருக்கும் எந்த செயல்முறையையும் எழுப்ப முயற்சிக்கிறோம். நமக்குத் தேவையான அளவு பைட்டுகளை எழுத முடிந்ததா என்று பார்க்க ஆரம்பத்திற்குச் செல்கிறோம். இல்லையெனில், நாங்கள் ஒரு புதிய பதிவு சுழற்சியைத் தொடங்குகிறோம்.
பொதுவாக அளவுரு i_mode அனுமதிகளை சேமிக்க inode பயன்படுகிறது 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()அது பைப்லைனில் சில தரவுகளை எழுதும் போது.
கருத்துகள் "அளவுருக்களை அனுப்புவதற்குப் பதிலாக அதைப் புரிந்துகொள்ள உதவும்.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, ஒரு எளிய Unix-போன்ற கர்னல்
ஒரு கருவை உருவாக்க யூனிக்ஸ் ஆறாவது பதிப்பின் தாக்கம், ஆனால் x86 செயலிகளில் இயங்க நவீன C இல் எழுதப்பட்டது. குறியீடு படிக்க எளிதானது மற்றும் புரிந்துகொள்ளக்கூடியது. மேலும், TUHS உடன் Unix மூலங்களைப் போலல்லாமல், நீங்கள் அதை தொகுக்கலாம், மாற்றலாம் மற்றும் PDP 11/70 அல்லாத வேறு ஏதாவது ஒன்றில் இயக்கலாம். எனவே, இந்த மையமானது இயக்க முறைமைகளில் கற்பிக்கும் பொருளாக பல்கலைக்கழகங்களில் பரவலாகப் பயன்படுத்தப்படுகிறது. ஆதாரங்கள் .
குறியீடு தெளிவான மற்றும் சிந்தனைமிக்க செயலாக்கத்தைக் கொண்டுள்ளது , வட்டில் ஐனோடுக்குப் பதிலாக நினைவகத்தில் ஒரு இடையகத்தால் ஆதரிக்கப்படுகிறது. இங்கே நான் "கட்டமைப்பு குழாய்" மற்றும் செயல்பாட்டின் வரையறையை மட்டுமே தருகிறேன் 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 ஒரு போர்வையில் செயல்படுத்தப்படுகிறது . அவருடைய எல்லா குறியீடுகளையும் படிக்க பரிந்துரைக்கிறேன். சிக்கலானது ஆறாவது பதிப்பின் மூலக் குறியீட்டின் மட்டத்தில் உள்ளது, ஆனால் இது படிக்க மிகவும் எளிதானது மற்றும் மிகவும் இனிமையானது.
லினக்ஸ் 0.01
Linux 0.01க்கான மூலக் குறியீட்டை நீங்கள் காணலாம். அவரது குழாய்களை செயல்படுத்துவது குறித்து ஆய்வு செய்வது அறிவுறுத்தலாக இருக்கும் fs/pipe.c. இங்கே, பைப்லைனைப் பிரதிநிதித்துவப்படுத்த ஒரு ஐனோட் பயன்படுத்தப்படுகிறது, ஆனால் பைப்லைன் நவீன 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;
}
struct வரையறைகளைப் பார்க்காமல் கூட, ஒரு எழுத்துச் செயல்பாடு விளைந்ததா என்பதைச் சரிபார்க்க ஐனோட் குறிப்பு எண்ணிக்கை எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை நீங்கள் கண்டுபிடிக்கலாம். 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 இல் திவி கபூர் எழுதிய கட்டுரை "லினக்ஸ் பைப்லைன்கள் (இதுவரை) எவ்வாறு செயல்படுகின்றன என்பது பற்றிய கண்ணோட்டம். ஏ இடைவினையின் பைப்லைன் மாதிரியை விளக்குகிறது, அதன் திறன்கள் தற்காலிக கோப்புகளை விட அதிகமாகும்; மேலும் ஆறாவது பதிப்பான யூனிக்ஸ் கர்னலில் பைப்லைன்கள் "மிகவும் கன்சர்வேடிவ் லாக்கிங்கில்" இருந்து எவ்வளவு தூரம் சென்றிருக்கிறது என்பதையும் காட்டுகிறது.
ஆதாரம்: www.habr.com