ইউনিক্সে কিভাবে পাইপলাইন প্রয়োগ করা হয়

এই নিবন্ধটি ইউনিক্স কার্নেলে পাইপলাইন বাস্তবায়নের বর্ণনা করে। আমি কিছুটা হতাশ হয়েছিলাম যে শিরোনাম একটি সাম্প্রতিক নিবন্ধইউনিক্সে কিভাবে পাইপলাইন কাজ করে?» দেখা গেল না অভ্যন্তরীণ কাঠামো সম্পর্কে। আমি কৌতূহলী হয়ে উত্তর খোঁজার জন্য পুরানো সূত্রে খনন করলাম।

এটা কিসের ব্যাপারে?

পাইপলাইনগুলি "সম্ভবত ইউনিক্সের সবচেয়ে গুরুত্বপূর্ণ আবিষ্কার" - ছোট প্রোগ্রামগুলিকে একত্রিত করার ইউনিক্সের অন্তর্নিহিত দর্শনের একটি সংজ্ঞায়িত বৈশিষ্ট্য এবং কমান্ড লাইনে পরিচিত শিলালিপি:

$ 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()সংযুক্ত ফাইল বর্ণনাকারী পেতে. একটি শিশু প্রক্রিয়া একজন বর্ণনাকারীকে লেখে এবং অন্য প্রক্রিয়া অন্য বর্ণনাকারী থেকে একই ডেটা পড়ে। শেলটি 2 এবং 3 বর্ণনাকারীকে "পুনর্নামকরণ" করে যা stdin এবং stdout এর সাথে মিলিত হয়।

পাইপলাইন ব্যতীত, শেলটিকে একটি ফাইলে একটি প্রক্রিয়ার আউটপুট লিখতে হবে এবং ফাইল থেকে ডেটা পড়ার জন্য অন্য প্রক্রিয়াতে পাইপ করতে হবে। ফলস্বরূপ, আমরা আরও সংস্থান এবং ডিস্কের স্থান নষ্ট করব। যাইহোক, পাইপলাইনগুলি অস্থায়ী ফাইলগুলি এড়ানোর চেয়ে আরও বেশি কিছুর জন্য ভাল:

যদি একটি প্রক্রিয়া একটি খালি পাইপলাইন থেকে পড়ার চেষ্টা করে, তাহলে read(2) ডেটা উপলব্ধ না হওয়া পর্যন্ত ব্লক করা হবে। যদি একটি প্রক্রিয়া একটি সম্পূর্ণ পাইপলাইনে লেখার চেষ্টা করে, তাহলে write(2) লেখাটি সম্পূর্ণ করার জন্য পাইপলাইন থেকে পর্যাপ্ত ডেটা পড়া না হওয়া পর্যন্ত ব্লক করা হবে।

POSIX প্রয়োজনীয়তার মতো, এটি একটি গুরুত্বপূর্ণ সম্পত্তি: পাইপলাইনে লেখা পর্যন্ত PIPE_BUF বাইট (অন্তত 512) অবশ্যই পারমাণবিক হতে হবে যাতে প্রক্রিয়াগুলি পাইপলাইনের মাধ্যমে একে অপরের সাথে এমনভাবে যোগাযোগ করতে পারে যা সাধারণ ফাইলগুলি (যা এই ধরনের গ্যারান্টি প্রদান করে না) পারে না।

একটি নিয়মিত ফাইলের সাথে, একটি প্রক্রিয়া এটিতে তার সমস্ত আউটপুট লিখতে পারে এবং এটি অন্য প্রক্রিয়াতে প্রেরণ করতে পারে। অথবা প্রসেসগুলি একটি কঠিন সমান্তরাল মোডে কাজ করতে পারে, একটি বাহ্যিক সংকেত প্রক্রিয়া (যেমন একটি সেমাফোর) ব্যবহার করে একে অপরকে লেখা বা পড়া সম্পূর্ণ হওয়ার বিষয়ে অবহিত করতে পারে। কনভেয়াররা আমাদের এই সমস্ত ঝামেলা থেকে বাঁচায়।

আমরা কি খোঁজ করছি?

একটি পরিবাহক কিভাবে কাজ করতে পারে তা কল্পনা করা আপনার জন্য সহজ করার জন্য আমি আমার আঙ্গুলের উপর ব্যাখ্যা করব। আপনাকে মেমরিতে একটি বাফার এবং কিছু রাজ্য বরাদ্দ করতে হবে। বাফার থেকে ডেটা যোগ করতে এবং অপসারণ করতে আপনার ফাংশনগুলির প্রয়োজন হবে। ফাইল বর্ণনাকারীতে রিড এবং রাইট অপারেশনের সময় ফাংশন কল করার জন্য আপনার কিছু সুবিধার প্রয়োজন হবে। এবং উপরে বর্ণিত বিশেষ আচরণ বাস্তবায়নের জন্য লকগুলির প্রয়োজন।

আমরা এখন আমাদের অস্পষ্ট মানসিক মডেলকে নিশ্চিত বা খণ্ডন করতে উজ্জ্বল আলোর নিচে কার্নেলের সোর্স কোড জিজ্ঞাসাবাদ করতে প্রস্তুত। তবে সবসময় অপ্রত্যাশিত ঘটনার জন্য প্রস্তুত থাকুন।

আমরা কোথায় খুঁজছি?

আমি জানি না আমার বিখ্যাত বইটির কপি কোথায় আছে।সিংহ বই« ইউনিক্স 6 সোর্স কোড সহ, কিন্তু ধন্যবাদ ইউনিক্স হেরিটেজ সোসাইটি অনলাইনে অনুসন্ধান করা যেতে পারে সোর্স কোড এমনকি ইউনিক্সের পুরানো সংস্করণ।

টিইউএইচএস আর্কাইভের মধ্য দিয়ে ঘুরে বেড়ানো একটি যাদুঘর দেখার মতো। আমরা আমাদের ভাগ করা ইতিহাসের দিকে তাকাতে পারি এবং পুরানো ক্যাসেট এবং প্রিন্টআউটগুলি থেকে বিট করে এই সমস্ত উপাদান পুনরুদ্ধার করার জন্য বছরের পর বছর প্রচেষ্টার জন্য আমি সম্মান করি। এবং আমি সেই টুকরোগুলি সম্পর্কে তীব্রভাবে সচেতন যেগুলি এখনও অনুপস্থিত৷

পাইপলাইনগুলির প্রাচীন ইতিহাস সম্পর্কে আমাদের কৌতূহলকে সন্তুষ্ট করার পরে, আমরা তুলনা করার জন্য আধুনিক কোরগুলি দেখতে পারি।

উপায় দ্বারা, pipe টেবিলে সিস্টেম কল নম্বর 42 sysent[]. কাকতালীয়?

ঐতিহ্যগত ইউনিক্স কার্নেল (1970-1974)

আমি কোন চিহ্ন খুঁজে পাইনি pipe(2) মধ্যে না PDP-7 ইউনিক্স (জানুয়ারি 1970), বা না প্রথম সংস্করণ ইউনিক্স (নভেম্বর 1971), বা অসম্পূর্ণ সোর্স কোডে দ্বিতীয় সংস্করণ (জুন 1972)।

এমন দাবি করেছে টিইউএইচএস তৃতীয় সংস্করণ ইউনিক্স (ফেব্রুয়ারি 1973) পাইপলাইন সহ প্রথম সংস্করণ ছিল:

ইউনিক্সের তৃতীয় সংস্করণটি ছিল অ্যাসেম্বলারে লেখা কার্নেল সহ শেষ সংস্করণ, তবে পাইপলাইন সহ প্রথম সংস্করণও। 1973-এর সময়, তৃতীয় সংস্করণের উন্নতির জন্য কাজ চলছিল, কার্নেলটি সি-তে পুনরায় লেখা হয়েছিল এবং এইভাবে ইউনিক্সের চতুর্থ সংস্করণের জন্ম হয়েছিল।

একজন পাঠক একটি নথির একটি স্ক্যান খুঁজে পেয়েছেন যেখানে ডগ ম্যাকিলরয় "বাগানের পায়ের পাতার মোজাবিশেষের মতো প্রোগ্রামগুলিকে সংযুক্ত করার" ধারণাটি প্রস্তাব করেছিলেন।

ব্রায়ান কার্নিগানের বইতেইউনিক্স: একটি ইতিহাস এবং একটি স্মৃতিচারণ", কনভেয়রদের উপস্থিতির ইতিহাসে এই নথিটিও উল্লেখ করা হয়েছে: "... এটি 30 বছর ধরে বেল ল্যাবসে আমার অফিসের দেয়ালে ঝুলছে।" এখানে McIlroy সঙ্গে সাক্ষাৎকারএবং থেকে আরেকটি গল্প McIlroy এর কাজ, 2014 সালে লেখা:

যখন ইউনিক্স আবির্ভূত হয়, কোরোটিনগুলির প্রতি আমার আবেগ আমাকে OS লেখক, কেন থম্পসনকে কিছু প্রক্রিয়ায় লিখিত ডেটা শুধুমাত্র ডিভাইসে নয়, অন্য প্রক্রিয়ায় প্রস্থান করার অনুমতি দিতে বলেছিল। কেন ভেবেছিল এটা সম্ভব। যাইহোক, একটি মিনিমালিস্ট হিসাবে, তিনি প্রতিটি সিস্টেম বৈশিষ্ট্য একটি গুরুত্বপূর্ণ ভূমিকা পালন করতে চেয়েছিলেন। একটি মধ্যবর্তী ফাইল লেখার চেয়ে প্রক্রিয়াগুলির মধ্যে সরাসরি লেখা কি সত্যিই একটি বড় সুবিধা? এবং শুধুমাত্র যখন আমি আকর্ষণীয় নাম "পাইপলাইন" এবং প্রক্রিয়াগুলির মিথস্ক্রিয়া সিনট্যাক্সের একটি বিবরণ দিয়ে একটি নির্দিষ্ট প্রস্তাব দিয়েছিলাম, কেন অবশেষে চিৎকার করে বলেছিলেন: "আমি এটি করব!"।

এবং করেছে। এক দুর্ভাগ্যজনক সন্ধ্যায়, কেন কার্নেল এবং শেল পরিবর্তন করে, তারা কীভাবে ইনপুট গ্রহণ করে (যা একটি পাইপলাইন থেকে আসতে পারে) মানসম্মত করার জন্য বেশ কয়েকটি স্ট্যান্ডার্ড প্রোগ্রাম ঠিক করে এবং ফাইলের নাম পরিবর্তন করে। পরের দিন, পাইপলাইনগুলি অ্যাপ্লিকেশনগুলিতে খুব ব্যাপকভাবে ব্যবহৃত হয়েছিল। সপ্তাহের শেষের দিকে, সচিবরা ওয়ার্ড প্রসেসর থেকে প্রিন্টারে নথি পাঠাতে তাদের ব্যবহার করেন। কিছুটা পরে, কেন ক্লিনার কনভেনশনের সাথে পাইপলাইনের ব্যবহার মোড়ানোর জন্য আসল API এবং সিনট্যাক্স প্রতিস্থাপন করে যা তখন থেকেই ব্যবহৃত হয়ে আসছে।

দুর্ভাগ্যবশত, ইউনিক্স কার্নেলের তৃতীয় সংস্করণের সোর্স কোড হারিয়ে গেছে। এবং যদিও আমাদের কার্নেল সোর্স কোড সি-তে লেখা আছে চতুর্থ সংস্করণ, যা 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)। ব্যাপকভাবে ধন্যবাদ লায়ন্স পূর্ববর্তী সংস্করণগুলির উত্সগুলির তুলনায় এটি খুঁজে পাওয়া অনেক সহজ:

বহু বছর ধরে বই লায়ন্স বেল ল্যাবসের বাইরে উপলব্ধ ইউনিক্স কার্নেলের একমাত্র নথি ছিল। যদিও ষষ্ঠ সংস্করণের লাইসেন্স শিক্ষকদের এর উৎস কোড ব্যবহার করার অনুমতি দেয়, সপ্তম সংস্করণের লাইসেন্স এই সম্ভাবনাকে বাদ দিয়েছিল, তাই বইটি অবৈধ টাইপলিখিত কপিগুলিতে বিতরণ করা হয়েছিল।

আজ আপনি বইটির একটি পুনঃমুদ্রণ কপি কিনতে পারেন, যার কভারটি কপিয়ারে শিক্ষার্থীদের চিত্রিত করে। এবং ওয়ারেন টুমিকে ধন্যবাদ (যিনি TUHS প্রকল্প শুরু করেছেন), আপনি ডাউনলোড করতে পারেন ষষ্ঠ সংস্করণের উৎস পিডিএফ. আমি আপনাকে একটি ধারণা দিতে চাই যে ফাইলটি তৈরি করতে কতটা প্রচেষ্টা করা হয়েছে:

15 বছরেরও বেশি আগে, আমি প্রদত্ত সোর্স কোডের একটি কপি টাইপ করেছিলাম লায়ন্সকারণ আমি অজানা সংখ্যক অন্য কপি থেকে আমার কপির মান পছন্দ করিনি। TUHS এখনও বিদ্যমান ছিল না, এবং আমার কাছে পুরানো উত্সগুলিতে অ্যাক্সেস ছিল না। কিন্তু 1988 সালে আমি 9টি ট্র্যাক সহ একটি পুরানো টেপ পেয়েছি যা একটি PDP11 কম্পিউটার থেকে ব্যাকআপ ছিল। এটি কাজ করে কিনা তা জানা কঠিন ছিল, তবে একটি অক্ষত /usr/src/ গাছ ছিল যেখানে বেশিরভাগ ফাইল 1979 চিহ্নিত করা হয়েছিল, যা তখনও প্রাচীন বলে মনে হয়েছিল। এটা ছিল সপ্তম সংস্করণ, বা PWB ডেরিভেটিভ, আমি ভেবেছিলাম।

আমি ফাইন্ডটিকে একটি ভিত্তি হিসাবে নিয়েছি এবং ষষ্ঠ সংস্করণের অবস্থায় ম্যানুয়ালি সূত্রগুলিকে সম্পাদনা করেছি। কোডের অংশটি একই রয়ে গেছে, অংশটি সামান্য সম্পাদনা করতে হয়েছিল, আধুনিক টোকেন += অপ্রচলিত =+ এ পরিবর্তন করে। কিছু সহজভাবে মুছে ফেলা হয়েছিল, এবং কিছু সম্পূর্ণরূপে পুনরায় লিখতে হয়েছিল, কিন্তু খুব বেশি নয়।

এবং আজ আমরা টিইউএইচএস-এর ষষ্ঠ সংস্করণের সোর্স কোড অনলাইনে পড়তে পারি আর্কাইভ, যেখানে ডেনিস রিচির হাত ছিল.

যাইহোক, প্রথম নজরে, কার্নিঘন এবং রিচির সময়কালের আগে সি-কোডের প্রধান বৈশিষ্ট্য হল এটি সংক্ষিপ্ততা. এটা প্রায়ই নয় যে আমি আমার সাইটে তুলনামূলকভাবে সংকীর্ণ ডিসপ্লে এলাকায় ফিট করার জন্য বিস্তৃত সম্পাদনা ছাড়াই কোডের স্নিপেট সন্নিবেশ করতে সক্ষম হই।

শুরুতে /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;
}

মন্তব্য স্পষ্টভাবে বর্ণনা করে এখানে কি ঘটছে. কিন্তু কোডটি বোঝা এত সহজ নয়, আংশিকভাবে কিভাবে "struct ব্যবহারকারী u» এবং রেজিস্টার R0 и R1 সিস্টেম কল প্যারামিটার এবং রিটার্ন মান পাস করা হয়।

এর সাথে চেষ্টা করা যাক ialloc() ডিস্কে রাখুন ইনোড (আইনোড), এবং সাহায্যে 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'a (একটি খালি পাইপলাইন 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 ইনোডে আমরা অবস্থানটি 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, একটি সাধারণ ইউনিক্স-এর মতো কার্নেল

নিউক্লিয়াস তৈরি করতে Xv6 ইউনিক্সের ষষ্ঠ সংস্করণ দ্বারা প্রভাবিত, কিন্তু x86 প্রসেসরে চালানোর জন্য আধুনিক সি-তে লেখা। কোড পড়া সহজ এবং বোধগম্য. এছাড়াও, 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. এখানে, পাইপলাইনের প্রতিনিধিত্ব করার জন্য একটি ইনোড ব্যবহার করা হয়েছে, কিন্তু পাইপলাইনটি নিজেই আধুনিক সি-তে লেখা আছে। আপনি যদি ষষ্ঠ সংস্করণ কোডটি হ্যাক করে থাকেন, তাহলে এখানে আপনার কোনো সমস্যা হবে না। এই ফাংশন মত দেখায় কি 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 এত বিদেশী দেখায় না।

আধুনিক লিনাক্স কার্নেল, ফ্রিবিএসডি, নেটবিএসডি, ওপেনবিএসডি

আমি দ্রুত কিছু আধুনিক কার্নেলের উপর গিয়েছিলাম। তাদের মধ্যে ইতিমধ্যে একটি ডিস্ক-ভিত্তিক বাস্তবায়ন নেই (আশ্চর্যজনক নয়)। লিনাক্স এর নিজস্ব বাস্তবায়ন আছে। এবং যদিও তিনটি আধুনিক BSD কার্নেলে জন ডাইসনের লেখা কোডের উপর ভিত্তি করে বাস্তবায়ন রয়েছে, বছরের পর বছর ধরে তারা একে অপরের থেকে খুব আলাদা হয়ে গেছে।

পড়তে fs/pipe.c (লিনাক্সে) বা sys/kern/sys_pipe.c (*BSD-তে), এর জন্য সত্যিকারের উত্সর্গ লাগে। ভেক্টর এবং অ্যাসিঙ্ক্রোনাস I/O-এর মতো বৈশিষ্ট্যগুলির জন্য কার্যকারিতা এবং সমর্থন আজ কোডে গুরুত্বপূর্ণ। এবং মেমরি বরাদ্দ, লক, এবং কার্নেল কনফিগারেশনের বিশদগুলি ব্যাপকভাবে পরিবর্তিত হয়। এটি অপারেটিং সিস্টেমের একটি প্রাথমিক কোর্সের জন্য বিশ্ববিদ্যালয়গুলির প্রয়োজন নয়৷

যাই হোক না কেন, কয়েকটি পুরানো নিদর্শন (উদাহরণস্বরূপ, তৈরি করা) আবিষ্কার করা আমার জন্য আকর্ষণীয় ছিল SIGPIPE এবং বিনিময়ে EPIPE একটি বন্ধ পাইপলাইনে লেখার সময়) এই সমস্ত, এত ভিন্ন, আধুনিক কার্নেলগুলিতে। আমি সম্ভবত PDP-11 কম্পিউটার লাইভ দেখতে পাব না, তবে আমার জন্মের কয়েক বছর আগে লেখা কোড থেকে এখনও অনেক কিছু শেখার আছে।

2011 সালে দিভি কাপুর লিখেছিলেন, নিবন্ধটি "পাইপ এবং FIFO-এর লিনাক্স কার্নেল বাস্তবায়নকিভাবে লিনাক্স পাইপলাইন (এখন পর্যন্ত) কাজ করে তার একটি ওভারভিউ। ক লিনাক্সে সাম্প্রতিক প্রতিশ্রুতি ইন্টারঅ্যাকশনের পাইপলাইন মডেলকে চিত্রিত করে, যার ক্ষমতা অস্থায়ী ফাইলগুলির চেয়ে বেশি; এবং ইউনিক্স কার্নেলের ষষ্ঠ সংস্করণে "খুব রক্ষণশীল লকিং" থেকে পাইপলাইনগুলি কতদূর চলে গেছে তাও দেখায়।

উত্স: www.habr.com