របៀបដែលបំពង់ត្រូវបានអនុវត្តនៅក្នុង Unix

អត្ថបទនេះពិពណ៌នាអំពីការអនុវត្តបំពង់នៅក្នុងខឺណែលយូនីក។ ខ្ញុំ​មាន​ការ​ខក​ចិត្ត​បន្តិច​ដែល​អត្ថបទ​ថ្មី​មួយ​មាន​ចំណង​ជើង​ថា "តើបំពង់បង្ហូរប្រេងដំណើរការយ៉ាងដូចម្តេចនៅក្នុង Unix?» បានប្រែក្លាយ មិនមាន អំពីរចនាសម្ព័ន្ធផ្ទៃក្នុង។ ខ្ញុំ​មាន​ការ​ចង់​ដឹង​ចង់​ឃើញ​ហើយ​បាន​ជីក​រក​ប្រភព​ចាស់​ដើម្បី​ស្វែង​រក​ចម្លើយ។

តើយើងកំពុងនិយាយអំពីអ្វី?

បំពង់គឺ "ប្រហែលជាការច្នៃប្រឌិតដ៏សំខាន់បំផុតនៅក្នុងយូនីក" ដែលជាលក្ខណៈកំណត់នៃទស្សនវិជ្ជាមូលដ្ឋានរបស់យូនីកក្នុងការដាក់កម្មវិធីតូចៗរួមគ្នា និងពាក្យស្លោកបន្ទាត់ពាក្យបញ្ជាដែលធ្លាប់ស្គាល់៖

$ 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 ជាមួយ dup4 ដើម្បីផ្គូផ្គង stdin និង stdout ។

បើគ្មានបំពង់ទេ សែលនឹងត្រូវសរសេរលទ្ធផលនៃដំណើរការមួយទៅឯកសារមួយ ហើយបញ្ជូនវាទៅដំណើរការមួយទៀត ដើម្បីអានទិន្នន័យពីឯកសារ។ ជាលទ្ធផល យើងនឹងខ្ជះខ្ជាយធនធាន និងទំហំថាសកាន់តែច្រើន។ ទោះជាយ៉ាងណាក៏ដោយ បំពង់បង្ហូរប្រេងគឺល្អសម្រាប់ច្រើនជាងការជៀសវាងឯកសារបណ្តោះអាសន្ន៖

ប្រសិនបើដំណើរការមួយព្យាយាមអានពីបំពង់បង្ហូរទទេ read(2) នឹងរារាំងរហូតដល់ទិន្នន័យមាន។ ប្រសិនបើដំណើរការមួយព្យាយាមសរសេរទៅកាន់បំពង់ពេញលេញ write(2) នឹងរារាំងរហូតដល់ទិន្នន័យគ្រប់គ្រាន់ត្រូវបានអានពីបំពង់បង្ហូរដើម្បីបញ្ចប់ការសរសេរ។

ដូចជាតម្រូវការ POSIX នេះគឺជាទ្រព្យសម្បត្តិសំខាន់មួយ៖ ការសរសេរទៅកាន់បំពង់បង្ហូររហូតដល់ PIPE_BUF បៃ (យ៉ាងហោចណាស់ 512) ត្រូវតែជាអាតូមិក ដូច្នេះដំណើរការអាចទាក់ទងគ្នាទៅវិញទៅមកតាមរយៈបំពង់បង្ហូរប្រេងតាមរបៀបដែលឯកសារធម្មតា (ដែលមិនផ្តល់ការធានាបែបនេះ) មិនអាចធ្វើបាន។

ជាមួយនឹងឯកសារធម្មតា ដំណើរការមួយអាចសរសេរលទ្ធផលទាំងអស់របស់វាទៅវា ហើយបញ្ជូនវាទៅដំណើរការផ្សេងទៀត។ ឬដំណើរការអាចដំណើរការក្នុងរបៀបប៉ារ៉ាឡែលរឹង ដោយប្រើយន្តការផ្តល់សញ្ញាខាងក្រៅ (ដូចជា semaphore) ដើម្បីជូនដំណឹងដល់គ្នាទៅវិញទៅមកអំពីការបញ្ចប់ការសរសេរ ឬអាន។ Conveyors ជួយសង្រ្គោះយើងពីបញ្ហាទាំងអស់នេះ។

តើយើងកំពុងស្វែងរកអ្វី?

ខ្ញុំនឹងពន្យល់នៅលើម្រាមដៃរបស់ខ្ញុំដើម្បីធ្វើឱ្យវាកាន់តែងាយស្រួលសម្រាប់អ្នកក្នុងការស្រមៃពីរបៀបដែលឧបករណ៍បញ្ជូនអាចដំណើរការបាន។ អ្នកនឹងត្រូវបែងចែកសតិបណ្ដោះអាសន្ន និងស្ថានភាពមួយចំនួននៅក្នុងសតិ។ អ្នកនឹងត្រូវការមុខងារដើម្បីបន្ថែម និងលុបទិន្នន័យចេញពីសតិបណ្ដោះអាសន្ន។ អ្នកនឹងត្រូវការឧបករណ៍មួយចំនួនដើម្បីហៅមុខងារកំឡុងពេលប្រតិបត្តិការអាន និងសរសេរលើអ្នកពណ៌នាឯកសារ។ ហើយការចាក់សោគឺចាំបាច់ដើម្បីអនុវត្តអាកប្បកិរិយាពិសេសដែលបានពិពណ៌នាខាងលើ។

ឥឡូវនេះ យើងបានត្រៀមខ្លួនរួចរាល់ហើយ ដើម្បីសាកសួរប្រភពកូដនៃខឺណែល ក្រោមពន្លឺចង្កៀងភ្លឺច្បាស់ ដើម្បីបញ្ជាក់ ឬបដិសេធគំរូផ្លូវចិត្តមិនច្បាស់លាស់របស់យើង។ ប៉ុន្តែត្រូវត្រៀមខ្លួនជានិច្ចសម្រាប់អ្វីដែលមិនបានរំពឹងទុក។

តើយើងកំពុងរកមើលនៅឯណា?

ខ្ញុំមិនដឹងថាច្បាប់ចម្លងសៀវភៅដ៏ល្បីល្បាញរបស់ខ្ញុំនៅឯណាទេ។សៀវភៅសត្វតោ« ជាមួយនឹងកូដប្រភព Unix 6 ប៉ុន្តែអរគុណចំពោះ សមាគមបេតិកភណ្ឌយូនីក អាចស្វែងរកតាមអ៊ីនធឺណិត ប្រភព​កូដ សូម្បីតែកំណែចាស់របស់យូនីក។

ការដើរឆ្លងកាត់បណ្ណសារ TUHS គឺដូចជាការទៅទស្សនាសារមន្ទីរ។ យើងអាចមើលប្រវត្តិសាស្រ្តដែលបានចែករំលែករបស់យើង ហើយខ្ញុំមានការគោរពចំពោះកិច្ចខិតខំប្រឹងប្រែងជាច្រើនឆ្នាំដើម្បីយកមកវិញនូវសម្ភារៈទាំងអស់នេះបន្តិចម្តងៗពីកាសែត និងព្រីនចាស់។ ហើយ​ខ្ញុំ​ដឹង​យ៉ាង​ច្បាស់​អំពី​បំណែក​ទាំងនោះ​ដែល​នៅ​បាត់។

ដោយពេញចិត្តនឹងការចង់ដឹងចង់ឃើញរបស់យើងអំពីប្រវត្តិបុរាណនៃបំពង់បង្ហូរប្រេង យើងអាចមើលស្នូលទំនើបសម្រាប់ការប្រៀបធៀប។

ដោយវិធីនេះ, pipe គឺជាការហៅប្រព័ន្ធលេខ 42 នៅក្នុងតារាង sysent[]. ចៃដន្យ?

ខឺណែល Unix ប្រពៃណី (1970-1974)

ខ្ញុំមិនបានរកឃើញដានណាមួយទេ។ pipe(2) មិននៅក្នុង PDP-7 Unix (ខែមករា 1970) ឬនៅក្នុង ការបោះពុម្ពលើកដំបូងរបស់យូនីក (ខែវិច្ឆិកា 1971) ឬនៅក្នុងកូដប្រភពមិនពេញលេញ ការបោះពុម្ពលើកទីពីរ (មិថុនា ១៩៧២)។

TUHS អះអាង​ដូច្នេះ Unix បោះពុម្ពលើកទីបី (ខែកុម្ភៈ 1973) គឺជាកំណែដំបូងដែលមានបំពង់:

ការបោះពុម្ពលើកទី 1973 នៃយូនីកគឺជាកំណែចុងក្រោយដែលមានខឺណែលដែលសរសេរនៅក្នុងឧបករណ៍ភ្ជាប់ ប៉ុន្តែក៏ជាកំណែដំបូងដែលមានបំពង់ផងដែរ។ ក្នុងកំឡុងឆ្នាំ XNUMX ការងារកំពុងដំណើរការដើម្បីកែលម្អការបោះពុម្ពលើកទី XNUMX ខឺណែលត្រូវបានសរសេរឡើងវិញនៅក្នុង C ហើយដូច្នេះការបោះពុម្ពលើកទី XNUMX នៃយូនីកបានកើត។

អ្នកអានម្នាក់បានរកឃើញការស្កែនឯកសារដែល Doug McIlroy ស្នើគំនិតនៃ "ការភ្ជាប់កម្មវិធីដូចជាទុយោសួន"។

នៅក្នុងសៀវភៅរបស់ Brian Kernighanយូនីក៖ ប្រវត្តិ និងអនុស្សាវរីយ៍” ប្រវត្តិនៃការលេចចេញនូវឧបករណ៍បញ្ជូនក៏រៀបរាប់អំពីឯកសារនេះផងដែរ៖ “… វាព្យួរនៅលើជញ្ជាំងក្នុងការិយាល័យរបស់ខ្ញុំនៅ Bell Labs អស់រយៈពេល 30 ឆ្នាំ”។ នៅទីនេះ បទសម្ភាសន៍ជាមួយ McIlroyនិងរឿងមួយទៀតពី ស្នាដៃរបស់ McIlroy សរសេរក្នុងឆ្នាំ ២០១៤:

នៅពេលដែល Unix បានបង្ហាញខ្លួន ចំណង់ចំណូលចិត្តរបស់ខ្ញុំចំពោះ coroutines បានធ្វើឱ្យខ្ញុំសុំឱ្យអ្នកនិពន្ធ OS គឺ Ken Thompson អនុញ្ញាតឱ្យទិន្នន័យដែលបានសរសេរទៅដំណើរការមួយចំនួនមិនត្រឹមតែទៅកាន់ឧបករណ៍ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងទៅកាន់ដំណើរការផ្សេងទៀតផងដែរ។ Ken គិតថាវាអាចទៅរួច។ ទោះយ៉ាងណាក៏ដោយ ក្នុងនាមជាអ្នកតូចតាច គាត់ចង់ឱ្យគ្រប់ប្រព័ន្ធទាំងអស់ដើរតួយ៉ាងសំខាន់។ តើការសរសេរដោយផ្ទាល់រវាងដំណើរការពិតជាអត្ថប្រយោជន៍ធំជាងការសរសេរទៅកាន់ឯកសារកម្រិតមធ្យមមែនទេ? ហើយមានតែនៅពេលដែលខ្ញុំបានធ្វើសំណើជាក់លាក់មួយដែលមានឈ្មោះគួរឱ្យចាប់អារម្មណ៍ "បំពង់បង្ហូរប្រេង" និងការពិពណ៌នាអំពីវាក្យសម្ព័ន្ធនៃអន្តរកម្មនៃដំណើរការនោះ Ken បានលាន់មាត់ថា "ខ្ញុំនឹងធ្វើវា!" ។

ហើយបានធ្វើ។ ល្ងាចដ៏មានជោគវាសនាមួយ Ken បានផ្លាស់ប្តូរខឺណែល និងសែល ជួសជុលកម្មវិធីស្តង់ដារជាច្រើនដើម្បីកំណត់ស្តង់ដារពីរបៀបដែលពួកគេទទួលយកការបញ្ចូល (ដែលអាចមកពីបំពង់) និងផ្លាស់ប្តូរឈ្មោះឯកសារ។ នៅថ្ងៃបន្ទាប់បំពង់ត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយនៅក្នុងកម្មវិធី។ នៅចុងសប្តាហ៍ លេខាធិការបានប្រើពួកគេដើម្បីផ្ញើឯកសារពីកម្មវិធីវាយអត្ថបទទៅម៉ាស៊ីនបោះពុម្ព។ បន្តិចក្រោយមក Ken បានជំនួស API ដើម និងវាក្យសម្ព័ន្ធសម្រាប់រុំការប្រើប្រាស់បំពង់ជាមួយនឹងអនុសញ្ញាស្អាតជាងមុន ដែលត្រូវបានប្រើតាំងពីពេលនោះមក។

ជាអកុសល កូដប្រភពសម្រាប់ខឺណែល Unix បោះពុម្ពលើកទីបីត្រូវបានបាត់បង់។ ហើយទោះបីជាយើងមានកូដប្រភពខឺណែលសរសេរជា C ការបោះពុម្ពលើកទីបួនដែលត្រូវបានចេញផ្សាយនៅក្នុងខែវិច្ឆិកា ឆ្នាំ 1973 ប៉ុន្តែវាចេញមកពីរបីខែមុនពេលការចេញផ្សាយជាផ្លូវការ ហើយមិនមានការអនុវត្តបំពង់ទេ។ វាជាការអាណិតដែលកូដប្រភពសម្រាប់លក្ខណៈពិសេស Unix រឿងព្រេងនិទាននេះត្រូវបានបាត់បង់ ប្រហែលជាជារៀងរហូត។

យើងមានអត្ថបទឯកសារសម្រាប់ pipe(2) ពីការចេញផ្សាយទាំងពីរ ដូច្នេះអ្នកអាចចាប់ផ្តើមដោយការស្វែងរកឯកសារ ការបោះពុម្ពលើកទីបី (សម្រាប់ពាក្យមួយចំនួន គូសបន្ទាត់ពីក្រោម "ដោយដៃ" ខ្សែអក្សរ ^ H អមដោយសញ្ញាគូសបញ្ជាក់!) ប្រូតូ-pipe(2) ត្រូវ​បាន​សរសេរ​នៅ​ក្នុង assembler ហើយ​ត្រឡប់​ឯកសារ​ពណ៌នា​តែ​មួយ​ប៉ុណ្ណោះ ប៉ុន្តែ​បាន​ផ្តល់​នូវ​មុខងារ​ស្នូល​ដែល​រំពឹង​ទុក​រួច​ហើយ៖

ការហៅតាមប្រព័ន្ធ បំពង់ បង្កើតយន្តការ I/O ដែលហៅថាបំពង់បង្ហូរ។ អ្នកពិពណ៌នាឯកសារដែលបានត្រឡប់មកវិញអាចត្រូវបានប្រើសម្រាប់ប្រតិបត្តិការអាន និងសរសេរ។ នៅពេលដែលអ្វីមួយត្រូវបានសរសេរទៅបំពង់បង្ហូរ វាផ្ទុកទិន្នន័យរហូតដល់ 504 បៃ បន្ទាប់ពីនោះដំណើរការសរសេរត្រូវបានផ្អាក។ នៅពេលអានពីបំពង់បង្ហូរ ទិន្នន័យដែលជាប់គាំងត្រូវបានយក។

នៅឆ្នាំបន្ទាប់ ខឺណែលត្រូវបានសរសេរឡើងវិញជា C និង បំពង់ (2) ការបោះពុម្ពលើកទីបួន ទទួលបានរូបរាងទំនើបរបស់វាជាមួយនឹងគំរូ "pipe(fildes)»:

ការហៅតាមប្រព័ន្ធ បំពង់ បង្កើតយន្តការ I/O ដែលហៅថា បំពង់បង្ហូរប្រេង។ អ្នកពិពណ៌នាឯកសារដែលបានត្រឡប់មកវិញអាចត្រូវបានប្រើនៅក្នុងប្រតិបត្តិការអាន និងសរសេរ។ នៅពេលដែលអ្វីមួយត្រូវបានសរសេរទៅកាន់បំពង់បង្ហូរនោះ អ្នកពិពណ៌នាបានត្រឡប់ក្នុង r1 (resp. fildes[1]) ត្រូវបានប្រើ ដែលផ្ទុកទិន្នន័យរហូតដល់ 4096 បៃ បន្ទាប់ពីនោះដំណើរការសរសេរត្រូវបានផ្អាក។ នៅពេលអានពីបំពង់ អ្នកពណ៌នាត្រឡប់ទៅ r0 (resp. fildes[0]) យកទិន្នន័យ។

វាត្រូវបានសន្មត់ថានៅពេលដែលបំពង់មួយត្រូវបានកំណត់ ដំណើរការអន្តរកម្មពីរ (ឬច្រើន) (បង្កើតឡើងដោយការអំពាវនាវជាបន្តបន្ទាប់ សម) នឹងបញ្ជូនទិន្នន័យពីបំពង់ដោយប្រើការហៅទូរសព្ទ អាន и សរសេរ.

សែលមានវាក្យសម្ព័ន្ធសម្រាប់កំណត់អារេលីនេអ៊ែរនៃដំណើរការដែលតភ្ជាប់តាមរយៈបំពង់។

ការហៅទូរសព្ទទៅអានពីបំពង់បង្ហូរទទេ (មិនមានទិន្នន័យដែលជាប់គាំង) ដែលមានចុងម្ខាង (អ្នកសរសេរឯកសារទាំងអស់ត្រូវបានបិទ) ត្រឡប់ "ចុងបញ្ចប់នៃឯកសារ" វិញ។ សរសេរការហៅទូរសព្ទក្នុងស្ថានភាពស្រដៀងគ្នានេះមិនត្រូវបានអើពើទេ។

ឆាប់​បំផុត ការអនុវត្តបំពង់ដែលបានបម្រុងទុក យោង ដល់ការបោះពុម្ពលើកទីប្រាំនៃយូនីក (ខែមិថុនា 1974) ប៉ុន្តែវាស្ទើរតែដូចគ្នាទៅនឹងអ្វីដែលបានបង្ហាញខ្លួននៅក្នុងការចេញផ្សាយបន្ទាប់។ មាន​តែ​មតិ​បន្ថែម ដូច្នេះ​ការ​បោះពុម្ព​លើក​ទី​ប្រាំ​អាច​ត្រូវ​បាន​រំលង។

Unix បោះពុម្ពលើកទីប្រាំមួយ (1975)

ចាប់ផ្តើមអានកូដប្រភពយូនីក ការបោះពុម្ពលើកទីប្រាំមួយ។ (ឧសភា 1975) ។ សូមថ្លែងអំណរគុណយ៉ាងជ្រាលជ្រៅចំពោះ តោ វាងាយស្រួលស្វែងរកជាងប្រភពនៃកំណែមុនៗ៖

អស់រយៈពេលជាច្រើនឆ្នាំសៀវភៅ តោ គឺជាឯកសារតែមួយគត់នៅលើខឺណែល Unix ដែលមាននៅខាងក្រៅ Bell Labs ។ ទោះបីជាអាជ្ញាប័ណ្ណបោះពុម្ពលើកទីប្រាំមួយអនុញ្ញាតឱ្យគ្រូបង្រៀនប្រើកូដប្រភពរបស់វាក៏ដោយ អាជ្ញាប័ណ្ណបោះពុម្ពលើកទីប្រាំពីរបានដកចេញនូវលទ្ធភាពនេះ ដូច្នេះសៀវភៅត្រូវបានចែកចាយជាច្បាប់ចម្លងដែលសរសេរដោយខុសច្បាប់។

ថ្ងៃនេះ អ្នកអាចទិញសៀវភៅដែលបោះពុម្ពឡើងវិញ គម្របដែលពណ៌នាសិស្សនៅម៉ាស៊ីនថតចម្លង។ ហើយសូមអរគុណដល់ Warren Toomey (ដែលបានចាប់ផ្តើមគម្រោង TUHS) អ្នកអាចទាញយកបាន។ បោះពុម្ពលើកទីប្រាំមួយ ប្រភព PDF. ខ្ញុំ​ចង់​ផ្ដល់​ឱ្យ​អ្នក​នូវ​គំនិត​មួយ​នៃ​ការ​ខិត​ខំ​ប៉ុន្មាន​បាន​ចូល​ទៅ​ក្នុង​ការ​បង្កើត​ឯកសារ​នេះ​:

ជាង 15 ឆ្នាំមុន ខ្ញុំបានវាយបញ្ចូលក្នុងច្បាប់ចម្លងនៃកូដប្រភពដែលបានផ្តល់ឱ្យ តោដោយសារតែខ្ញុំមិនចូលចិត្តគុណភាពនៃច្បាប់ចម្លងរបស់ខ្ញុំពីចំនួនច្បាប់ចម្លងផ្សេងទៀតដែលមិនស្គាល់។ TUHS មិនទាន់មាននៅឡើយទេ ហើយខ្ញុំមិនមានសិទ្ធិចូលប្រើប្រភពចាស់ទេ។ ប៉ុន្តែនៅឆ្នាំ 1988 ខ្ញុំបានរកឃើញកាសែតចាស់មួយដែលមាន 9 បទដែលមានការបម្រុងទុកពីកុំព្យូទ័រ PDP11 ។ វាពិបាកក្នុងការដឹងថាតើវាដំណើរការឬអត់ ប៉ុន្តែមានដើមឈើ /usr/src/ នៅដដែលដែលឯកសារភាគច្រើនត្រូវបានសម្គាល់នៅឆ្នាំ 1979 ដែលមើលទៅបុរាណ។ វាជាការបោះពុម្ពលើកទីប្រាំពីរ ឬជានិស្សន្ទវត្ថុ PWB ខ្ញុំគិតថា។

ខ្ញុំបានយកការស្វែងរកជាមូលដ្ឋាន ហើយកែសម្រួលប្រភពដោយដៃទៅជាស្ថានភាពនៃការបោះពុម្ពលើកទីប្រាំមួយ។ ផ្នែកនៃកូដនៅតែដដែល ផ្នែកត្រូវកែសម្រួលបន្តិច ដោយផ្លាស់ប្តូរនិមិត្តសញ្ញាទំនើប += ទៅជាលែងប្រើ =+។ អ្វីមួយត្រូវបានលុបចោលយ៉ាងសាមញ្ញ ហើយអ្វីមួយត្រូវសរសេរឡើងវិញទាំងស្រុង ប៉ុន្តែមិនច្រើនពេកទេ។

ហើយថ្ងៃនេះយើងអាចអានតាមអ៊ីនធឺណិតនៅ TUHS នូវកូដប្រភពនៃការបោះពុម្ពលើកទីប្រាំមួយ។ បណ្ណសារដែល Dennis Ritchie មានដៃ.

ដោយវិធីនេះ នៅ glance ដំបូង លក្ខណៈពិសេសចម្បងនៃ C-code មុនសម័យ Kernighan និង Ritchie គឺជារបស់វា។ ភាពខ្លី. វាមិនញឹកញាប់ទេដែលខ្ញុំអាចបញ្ចូលផ្នែកតូចៗនៃកូដដោយគ្មានការកែសម្រួលយ៉ាងទូលំទូលាយដើម្បីឱ្យសមនឹងផ្ទៃបង្ហាញតូចចង្អៀតនៅលើគេហទំព័ររបស់ខ្ញុំ។

នៅដើមដំបូង /usr/sys/ken/pipe.c មានមតិពន្យល់ (ហើយបាទ មានច្រើនទៀត /usr/sys/dmr):

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

ទំហំសតិបណ្ដោះអាសន្នមិនបានផ្លាស់ប្តូរទេចាប់តាំងពីការបោះពុម្ពលើកទីបួន។ ប៉ុន្តែនៅទីនេះ យើងឃើញថា ដោយគ្មានឯកសារសាធារណៈណាមួយ បំពង់បង្ហូរប្រេងនេះធ្លាប់ប្រើឯកសារជាកន្លែងផ្ទុកជំនួស!

ចំពោះឯកសារ LARG ពួកវាត្រូវគ្នា។ ទង់ជាតិអ៊ីដ្រូសែន LARGដែលត្រូវបានប្រើដោយ "ក្បួនដោះស្រាយអាសយដ្ឋានធំ" ដើម្បីដំណើរការ ប្លុកដោយប្រយោល។ ដើម្បីគាំទ្រប្រព័ន្ធឯកសារធំជាង។ ដោយសារ Ken បាននិយាយថា វាជាការប្រសើរជាងកុំប្រើវា ខ្ញុំរីករាយនឹងទទួលយកពាក្យរបស់គាត់សម្រាប់វា។

នេះគឺជាការហៅតាមប្រព័ន្ធពិត 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 user u» និងចុះឈ្មោះ R0 и R1 ប៉ារ៉ាម៉ែត្រហៅប្រព័ន្ធនិងតម្លៃត្រឡប់ត្រូវបានហុច។

តោះសាកល្បងជាមួយ ialloc() ដាក់នៅលើថាស អ៊ីណូត (inode)និងដោយមានជំនួយ falloc() - ទុកពីរ ឯកសារ. ប្រសិនបើអ្វីៗដំណើរការល្អ យើងនឹងកំណត់ទង់ដើម្បីកំណត់អត្តសញ្ញាណឯកសារទាំងនេះថាជាចុងទាំងពីរនៃបំពង់បង្ហូរប្រេង ចង្អុលពួកវាទៅអ៊ីណូដដូចគ្នា (ដែលចំនួនឯកសារយោងក្លាយជា 2) ហើយសម្គាល់អ៊ីណូដថាបានកែប្រែ និងកំពុងប្រើប្រាស់។ យកចិត្តទុកដាក់ចំពោះសំណើ ខ្ញុំ​ដាក់() នៅក្នុងផ្លូវមានកំហុសដើម្បីបន្ថយចំនួនយោងនៅក្នុង inode ថ្មី។

pipe() ដល់​ពេល​កំណត់ R0 и R1 ត្រឡប់លេខពិពណ៌នាឯកសារសម្រាប់ការអាន និងសរសេរ។ falloc() ត្រឡប់ទ្រនិចទៅរចនាសម្ព័ន្ធឯកសារ ប៉ុន្តែក៏ "ត្រឡប់" តាមរយៈ u.u_ar0[R0] និងអ្នកពិពណ៌នាឯកសារ។ នោះគឺលេខកូដត្រូវបានរក្សាទុក r file descriptor សម្រាប់អាន និងចាត់តាំងអ្នកពណ៌នាសម្រាប់សរសេរដោយផ្ទាល់ពី 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. ដំបូងយើងត្រូវចាក់សោ inode (សូមមើលខាងក្រោម plock/prele).

បន្ទាប់មកយើងពិនិត្យមើលចំនួនយោង inode ។ ដរាបណាចុងទាំងពីរនៃបំពង់បង្ហូរប្រេងនៅតែបើកចំហ បញ្ជរគួរតែជា 2។ យើងបន្តភ្ជាប់ទៅតំណមួយ (ពី rp->f_inode) ដូច្នេះប្រសិនបើបញ្ជរតិចជាង 2 នោះវាគួរតែមានន័យថាដំណើរការអានបានបិទចុងបញ្ចប់នៃបំពង់។ ម្យ៉ាង​ទៀត យើង​កំពុង​តែ​ព្យាយាម​សរសេរ​ទៅ​បំពង់​ដែល​បិទ​ជិត​ដែល​ជា​កំហុស។ លេខកូដកំហុសដំបូង EPIPE និងសញ្ញា SIGPIPE បានបង្ហាញខ្លួននៅក្នុងការបោះពុម្ពលើកទី XNUMX នៃយូនីក។

ប៉ុន្តែទោះបីជា conveyor បើកចំហក៏ដោយវាអាចពេញ។ ក្នុងករណីនេះ យើងដោះសោ ហើយចូលគេងដោយសង្ឃឹមថាដំណើរការមួយផ្សេងទៀតនឹងអានពីបំពង់បង្ហូរប្រេង និងបង្កើនទំហំទំនេរគ្រប់គ្រាន់នៅក្នុងនោះ។ នៅពេលយើងភ្ញាក់ពីដំណេក យើងត្រលប់ទៅការចាប់ផ្តើម ព្យួរសោម្តងទៀត ហើយចាប់ផ្តើមវដ្តនៃការសរសេរថ្មី។

ប្រសិនបើមានកន្លែងទំនេរគ្រប់គ្រាន់នៅក្នុងបំពង់នោះ យើងសរសេរទិន្នន័យទៅវាដោយប្រើ សរសេរ(). ប៉ារ៉ាម៉ែត្រ 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 នៅ inode ។ យើងកំណត់ទីតាំងឡើងវិញទៅ 0 ហើយព្យាយាមដាស់ដំណើរការណាមួយដែលចង់សរសេរទៅបំពង់។ យើងដឹងថានៅពេលដែល conveyor ពេញ។ writep() ដេកលក់នៅលើ ip+1. ហើយឥឡូវនេះ បំពង់បង្ហូរប្រេងគឺទទេ យើងអាចដាស់វាឱ្យដំណើរការឡើងវិញនូវវដ្តនៃការសរសេររបស់វា។

ប្រសិនបើគ្មានអ្វីត្រូវអានទេនោះ។ readp() អាចកំណត់ទង់ជាតិ IREAD ហើយដេកលក់ ip+2. យើងដឹងថាអ្វីដែលនឹងដាស់គាត់ writep()នៅពេលដែលវាសរសេរទិន្នន័យមួយចំនួនទៅបំពង់។

មតិយោបល់លើ read() និង 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() ចាក់សោ inodes រហូតដល់ពួកគេបញ្ចប់ ឬទទួលបានលទ្ធផល (ឧ 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 រងឥទ្ធិពលដោយការបោះពុម្ពលើកទីប្រាំមួយនៃយូនីក ប៉ុន្តែត្រូវបានសរសេរជា C ទំនើបដើម្បីដំណើរការលើប្រព័ន្ធដំណើរការ x86 ។ កូដគឺងាយស្រួលអាន និងអាចយល់បាន។ ដូចគ្នានេះផងដែរ មិនដូចប្រភព Unix ជាមួយ TUHS ទេ អ្នកអាចចងក្រងវា កែប្រែវា និងដំណើរការវានៅលើអ្វីផ្សេងក្រៅពី PDP 11/70 ។ ដូច្នេះហើយ ស្នូលនេះត្រូវបានគេប្រើប្រាស់យ៉ាងទូលំទូលាយនៅក្នុងសាកលវិទ្យាល័យជាសម្ភារៈបង្រៀនស្តីពីប្រព័ន្ធប្រតិបត្តិការ។ ប្រភព មាននៅលើ Github.

កូដមានការអនុវត្តច្បាស់លាស់ និងគិតគូរ បំពង់.cគាំទ្រដោយសតិបណ្ដោះអាសន្នក្នុងអង្គចងចាំ ជំនួសឱ្យអ៊ីណូតនៅលើថាស។ នៅទីនេះខ្ញុំផ្តល់ឱ្យតែនិយមន័យនៃ "បំពង់បង្ហូររចនាសម្ព័ន្ធ" និងមុខងារ 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. ខ្ញុំសូមណែនាំឱ្យអានកូដរបស់គាត់ទាំងអស់។ ភាពស្មុគស្មាញគឺនៅកម្រិតនៃកូដប្រភពនៃការបោះពុម្ពលើកទី XNUMX ប៉ុន្តែវាកាន់តែងាយស្រួលនិងរីករាយក្នុងការអាន។

លីនុច 0.01

អ្នកអាចស្វែងរកកូដប្រភពសម្រាប់លីនុច 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;
}

ទោះបីជាមិនបានមើលនិយមន័យរចនាសម្ព័ន្ធក៏ដោយ អ្នកអាចស្វែងយល់ពីរបៀបដែលចំនួនសេចក្តីយោង inode ត្រូវបានប្រើដើម្បីពិនិត្យមើលថាតើប្រតិបត្តិការសរសេរលទ្ធផលនៅក្នុង SIGPIPE. បន្ថែមពីលើការងារដោយបៃបៃមុខងារនេះងាយស្រួលក្នុងការប្រៀបធៀបជាមួយគំនិតខាងលើ។ សូម្បីតែតក្កវិជ្ជា sleep_on/wake_up មើលទៅមិនចម្លែកទេ។

ខឺណែលលីនុចទំនើប, FreeBSD, NetBSD, OpenBSD

ខ្ញុំបានឆ្លងកាត់ខឺណែលទំនើបមួយចំនួនយ៉ាងលឿន។ គ្មាននរណាម្នាក់ក្នុងចំណោមពួកគេមានការអនុវត្តដែលមានមូលដ្ឋានលើថាស (មិនគួរឱ្យភ្ញាក់ផ្អើលទេ) ។ លីនុចមានការអនុវត្តផ្ទាល់ខ្លួន។ ហើយទោះបីជាខឺណែល BSD ទំនើបទាំងបីមានការអនុវត្តដោយផ្អែកលើកូដដែលត្រូវបានសរសេរដោយ John Dyson ប៉ុន្មានឆ្នាំមកនេះ ពួកគេបានក្លាយទៅជាខុសគ្នាខ្លាំងពីគ្នាទៅវិញទៅមក។

អាន fs/pipe.c (នៅលើលីនុច) ឬ sys/kern/sys_pipe.c (នៅលើ *BSD) វាត្រូវការការលះបង់ពិតប្រាកដ។ ការអនុវត្ត និងការគាំទ្រសម្រាប់លក្ខណៈពិសេសដូចជាវ៉ិចទ័រ និងអសមកាល I/O មានសារៈសំខាន់នៅក្នុងកូដនាពេលបច្ចុប្បន្ននេះ។ ហើយព័ត៌មានលម្អិតនៃការបែងចែកអង្គចងចាំ ការចាក់សោ និងការកំណត់រចនាសម្ព័ន្ធខឺណែល មានភាពខុសប្លែកគ្នាយ៉ាងខ្លាំង។ នេះមិនមែនជាអ្វីដែលសាកលវិទ្យាល័យត្រូវការសម្រាប់វគ្គសិក្សាណែនាំអំពីប្រព័ន្ធប្រតិបត្តិការនោះទេ។

ក្នុងករណីណាក៏ដោយ វាជាការគួរឱ្យចាប់អារម្មណ៍សម្រាប់ខ្ញុំក្នុងការរកឃើញគំរូចាស់ៗមួយចំនួន (ឧទាហរណ៍ ការបង្កើត SIGPIPE និងត្រឡប់មកវិញ EPIPE នៅពេលសរសេរទៅបំពង់បិទជិត) នៅក្នុងទាំងអស់នេះ ខុសគ្នាខ្លាំងណាស់ ខឺណែលទំនើប។ ខ្ញុំប្រហែលជាមិនដែលឃើញកុំព្យូទ័រ PDP-11 ផ្ទាល់ទេ ប៉ុន្តែនៅមានច្រើនដែលត្រូវរៀនពីកូដដែលត្រូវបានសរសេរពីរបីឆ្នាំមុនខ្ញុំកើត។

និពន្ធដោយ Divi Kapoor ក្នុងឆ្នាំ 2011 អត្ថបទ "ការអនុវត្តខឺណែលលីនុចនៃបំពង់ និង FIFOsគឺជាទិដ្ឋភាពទូទៅនៃរបៀបដែលបំពង់លីនុច (រហូតមកដល់ពេលនេះ) ដំណើរការ។ ក ការប្តេជ្ញាចិត្តថ្មីៗនៅលើលីនុច បង្ហាញពីគំរូនៃអន្តរកម្មនៃបំពង់បង្ហូរប្រេង ដែលសមត្ថភាពរបស់វាលើសពីឯកសារបណ្តោះអាសន្ន។ ហើយក៏បង្ហាញផងដែរថាតើបំពង់បានទៅឆ្ងាយប៉ុណ្ណាពី "ការចាក់សោរបែបអភិរក្ស" នៅក្នុងខឺណែល Unix បោះពុម្ពលើកទីប្រាំមួយ។

ប្រភព: www.habr.com