Kuidas on Unixis realiseeritud torujuhtmed

Selles artiklis käsitletakse Unix-i tuumas konveierite rakendust. Olin mõnevõrra pettunud, et hiljutine artikkel pealkirjaga „Kuidas konveierid Unix-is töötavad?“ osutus ei siseküsimuseks. See äratas minu huvi ja hakkasin süvitsi kaevama vanadesse allikatesse, et vastust leida.

Mille üle jutt käib?

Konveierid on „tõenäoliselt kõige olulisem leiutis Unix-is” – need on määratlev omadus, mis põhineb Unix-i filosoofial, mille eesmärk on väikeste programmide ühendamine, samuti tuttav tekst käsureas:

$ echo hello | wc -c
6

See funktsionaalsus sõltub tuuma poolt pakutavast süsteemikõnest pipe, mis on dokumentatsiooni lehekülgedel kirjeldatud pipe(7) ja pipe(2):

Konveierid tagavad ühesuunalise kanali protsessidevaheliseks suhtlemiseks. Konveieril on sisend (write end) ja väljund (read end). Konveierisse kirjutatud andmeid saab lugeda väljundist.

Konveier luuakse väljundi kaudu pipe(2), mis tagastab kaks failideskriptorit: üks viitab konveieri sisendile, teine väljundile.

Ülaltoodud käsu jälgimisandmed näitavad konveieri loomist ja andmevoogu ühelt protsessilt teisele:

$ 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

Vanemprotsess kutsub välja pipe(), et saada ühendatud failikirjeldajad. Üks alamprotsess kirjutab ühte kirjelduse, teine aga loeb neid andmeid teisest kirjelduse.

Ilma torudeta peaks shell salvestama ühe protsessi tulemuse faili ja edastama selle teisele protsessile, et viimane saaks faili andmeid lugeda. Seetõttu raiskaksime rohkem ressursse ja kettaruumi. Kuid torud ei ole head mitte ainult selle poolest, et saavad vältida ajutiste failide kasutamist:

Kui protsess proovib lugeda tühjast torust, siis read(2) blokeerib seni, kuni andmed on saadaval. Kui protsess proovib kirjutada täidetud torusse, siis write(2) blokeerib kuni konveierist loetakse piisavalt andmeid kirje täitmiseks.

Nagu POSIX-nõue, on see oluline omadus: kirje konveierisse kuni PIPE_BUF baiti (vähemalt 512) peab olema aatomaarne, et protsessid saaksid üksteisega konveieri kaudu suhelda, nagu tavalised failid (mis ei paku selliseid garantiisid) ei suuda.

Tavalise faili kasutamisel saab protsess kirjutada sinna kõik oma väljundid ja edastada need teisele protsessile. Või protsessid saavad tegutseda rangelt paralleelselt, informeerides üksteist kirjutamise või lugemise lõpetamisest mõne välise signaalimehhanismi (nt semafori) kaudu. Konveierid vabastavad meid kõigist neist vaevadest.

Mida me otsime?

Selgitan lihtsalt, et oleksite paremini ette kujutada, kuidas konveier töötab. Teil on vaja eraldada mälu puhver ja mingi olek. Vajate funktsioone andmete lisamiseks ja eemaldamiseks puhvrist. Vajalik on mingi mehhanism, et kutsuda funktsioone välja lugemise ja kirjutamise operatsioonide käigus failidesse. Ja vajate lukke, et rakendada eespool kirjeldatud spetsiifilist käitumist.

Nüüd oleme valmis valgustama lähtekoodi tuuma, et kinnitada või ümber lükata meie ähmast mõttemudelit. Kuid olge alati valmis üllatusteks.

Kust me otsime?

Ma ei tea, kus mu eksemplar tuntud raamatust „Lions book„ Unix 6 lähtekoodiga asub, kuid tänu The Unix Heritage Society saame internetis otsida lähtekoodist veel vanemate versioonide Unix.

TUHS arhiivides ekslemine on nagu muuseumis käimine. Saame vaadata meie ühist ajalugu ning tunnen austust aastatepikkuste jõupingutuste vastu, et kõiki neid materjale bit haaval taastada vanadelt kassettidelt ja printimistelt. Ja tunnen teravalt puuduvaid fragmente.

Uurides konveierite iidset ajalugu, võime seniseks võrdluseks vaadata kaasaegseid südamikke.

Muide, pipe on süsteemikõne number 42 tabelis sysent[]. Kokk偶tus?

Traditsioonilised Unix südamikud (1970–1974)

Ma ei leidnud mingeid jälgi pipe(2) ei PDP-7 Unix (jaanuar 1970), ega esimese Unix väljaande (november 1971), ega puudulikust lähtekoodist teise väljaande (juuni 1972).

TUHS väidab, et kolmas Unix väljaanne (veebruar 1973) oli esimene versioon konveieritega:

Kolmas Unix väljaanne oli viimane versioon, mille südamik oli kirjutatud assambleekeeltes, kuid samas esimene versioon konveieridega. 1973. aastal tehti parandusi kolmandale väljaandele, südamik kirjutati ümber C-sse ja nii tekkis neljas Unix väljaanne.

Üks lugejatest leidis dokumendi koopia, kus Doug McIlroy pakkus ideed „programmide ühendamisest vooliku printsiibi järgides”.

Bryan Kernighani raamatus „Unix: A History and a Memoir“ mainitakse samuti seda dokumenti: „… see seisis 30 aastat mu Bell Labs’i kontori seinal.” Siin on intervjuu McIlroy’ga, ja veel üks lugu McIlroy töödest, kirjutatud 2014. aastal:

Kui Unix esmakordselt ilmus, põhjustas minu huvi korutinate vastu, et küsisin operatsioonisüsteemi autori, Ken Thompsoni, käest, kas andmed, mis on mõnes protsessis, saaksid suunata mitte ainult seadmele, vaid ka teise protsessi. Ken leidis, et see on võimalik. Siiski soovis ta minimalistina, et iga süsteemifunktsioon mängiks olulist rolli. Kas tõeliselt on otseprotsesside vahel kirjutamisel märkimisväärne eelis võrreldes ajutise faili kirjutamisega? Ja ainult siis, kui esitasin konkreetse ettepaneku silmatorkava nimega „toru“ koos protsessidevahelise suhtluse süntaksikirjeldusega, hüüdis Ken lõpuks: „Ma teen selle!“

Ja ja tegin. Ühel saatuslikul õhtul muutis Ken tuuma ja kestat, parandades mitmeid standardprogramme ning standardiseerides nende sisestamisprotseduurid (mida saab edastada konveieride kaudu) ning vahetas ka failide nimesid. Järgmisel päeval hakkasid konveierid rakendustes laialdaselt kasutusele minema. Nädala lõpuks saatis sekretäride abiga printerisse dokumente tekstiredaktorist. Veidi hiljem asendas Ken algse API ja konveierite kasutamise süntaksi puhtamate lepetega, mis on alates sellest ajast kasutusele võetud.

Kahjuks on kolmanda redaktsiooni Unix’i tuumakaallika kood kadunud. Ja kuigi meil on C keeles kirjutatud neljanda redaktsiooni tuumakaallika kood neljas redaktsioon, mis ilmus 1973. aasta novembris, ilmus see siiski paar kuud enne ametlikku väljalaskmist ning ei sisalda konveiere. Kahju, et Unix’i legendaarse funktsiooni algne kood on kadunud, võib-olla igaveseks.

Meil on dokumentatsiooni tekst pipe(2) mõlemast väljaandest, seega oleks mõttekas alustada dokumentatsiooni otsimisest kolmanda redaktsiooni (teatud sõnadega, mis on "käsi" alla joonitud, rida literiaalidest ^H, millele järgneb allajoonimine!). See proto-pipe(2) on kirjutatud assembleris ja tagastab ainult ühe failide kirjeldaja, kuid juba pakub oodatud põhifunktsionaalsust:

Süsteemikõne pipe loob sisse- ja väljundimehhanismi, mida nimetatakse toruks. Tagastatavat failide kirjeldajat saab kasutada lugemise ja kirjutamise operatsioonide jaoks. Kui torusse midagi kirjutatakse, siis puhverdub kuni 504 baitide andmeid, pärast mida kirjutamisprotsess peatub. Torust lugemisel võetakse puhverdatud andmed.

Järgmiseks aastaks tuum kirjutati ümber C-sse, ja pipe(2) neljandas väljaandes omandab oma kaasaegse kuju prototüübiga "pipe(fildes)»:

Süsteemikõne pipe loob sisend-väljund mehhanismi, mida nimetatakse toruks. Tagastatud failideskriptorit saab kasutada lugemis- ja kirjutamistoimingutes. Kui torusse midagi kirjutatakse, kasutatakse r1-s tagastatud deskriptorit (järelikult fildes[1]), mis puhverdab andmeid kuni 4096 baiti, pärast mida kirjutamisprotsess peatub. Torust lugemisel kasutab r0-s tagastatud deskriptor (järelikult fildes[0]) andmete saamiseks.

Oletatakse, et pärast toru määratlemist kahe (või enama) omavahel seotava protsessi (mis loodi järjestikuste kutsumistega fork) andmeid torust edastatakse, kasutades kutsungeid read ja write.

Käsklusel on süntaks lineaarsete protsesside massiivi määramiseks, mis on ühendatud toru kaudu.

Kutsungid, mis loevad tühjast torust (millel ei ole puhverdatud andmeid ja millel on ainult üks ots, sest kõik kirjutavad failideskriptorid on suletud), tagastavad "faili lõpu". Sarnastes olukordades kirjutamiskutsungid ignoreeritakse.

Varaseim säilinud toru rakendus kuulub Unix viienda väljaande juurde. (juuni 1974), kuid see on peaaegu identne järgmise versiooniga. Ainult kommentaarid lisandusid, seega võib viienda redaktsiooni vahele jätta.

Unix'i kuues redaktsioon (1975)

Alustame Unix'i allika koodi lugemist kuues redaktsioon (mai 1975). Suur osa tänu Lions on seda palju lihtsam leida kui varasemate versioonide allikaid:

Paljude aastate jooksul oli raamat Lions ainus Unix'i tuuma dokument, mis oli saadaval väljaspool Bell Labs'i. Kuigi kuue redaktsiooni litsents lubas õpetajatel seda allika koodi kasutada, välistas seitsmenda redaktsiooni litsents selle võimaluse, seega levis raamat ebaseaduslike trüki koopiatena.

Tänapäeval on saadaval raamat, mille kaanel on kujutatud üliõpilasi koopiamasinas. Ja tänu Warren Tumile (kes käivitas TUHS-i projekti) saate alla laadida PDF-faili kuue redaktsiooni allika koodiga. Tahan anda teile ülevaate, kui palju vaeva kulus faili loomisele:

Üle 15 aasta tagasi tippisin ma allika koodi koopia, mida toodi välja Lions, kuna mulle ei meeldinud minu koopia kvaliteet tundmatute teiste koopiate hulgast. TUHS ei olnud veel olemas ja mul ei olnud ligi vanadele lähtefailidele. Kuid 1988. aastal leidsin vana lintide, millel oli 9 rada ja millel oli koopia PDP11 arvutist. Oli raske mõista, kas see töötab, kuid seal oli puutumatu puu /usr/src/, kus enamik faile oli dateeritud 1979. aastaga, mis tundus juba toona muistsena. See oli seitsmes väljaanne või selle derivaat PWB, nagu ma arvasin.

Võtsin leiust aluseks ja redigeerisin lähtefailid käsitsi kuuenda väljaande seisundisse. Osa koodist jäi samaks, osa tuli veidi kohandada, muutes kaasaegse tokeni += vananenud =+. Midagi eemaldasin lihtsalt ja mõne pidin täielikult ümber kirjutama, kuid mitte liiga palju.

Ja täna saame veebis lugeda TUHS kuuenda väljaande lähtekoodi arhiivist, mille kallal töötas Dennis Ritchie.

Muide, esmapilgul on C-koodi peamine omadus kuni Kernighani ja Ritchie perioodini selle lühidus. Mul ei õnnestu sageli koodi fragmente ilma ulatusliku redigeerimiseta lisada, et need vastaksid minu saidil suhteliselt kitsale kuvamispiirkonnale.

Alguses /usr/sys/ken/pipe.c on selgitav kommentaar (ja jah, seal on veel /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

Puhvri suurus ei ole muutunud alates neljandast väljaandest. Kuid siin näeme, ilma igasuguse avaliku dokumentatsioonita, et kunagi kasutasid konveierid faile varunduslussu jaoks!

Mis puutub LARG-failidesse, siis need vastavad inode-lipule LARG, mida kasutatakse „suure aadressimise algoritmi“ kaudu kaudsete (indirect) blokki toetamiseks suuremate failisüsteemide jaoks. Kui Ken ütles, et parem on neid mitte kasutada, siis ma usun teda hea meelega.

Siin on tõeline süsteemikutse 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;
}

Kommentaaris on selgelt kirjas, mis toimub. Kuid koodis navigeerimine ei ole sugugi lihtne, osaliselt seetõttu, kuidas "struct user u" ja registrid R0 ja R1 edastavad süsteemikõnede parameetrid ja tagastatavad väärtused.

Proovime kasutada ialloc() kettal inode (indeksi descriptor), ning kasutada falloc() — mälu haldamiseks kahte faile. Kui kõik läheb hästi, seame lippu, et määrata need failid kahe otsa kaudu, märkides need sama inoodi (kus viidete loend saab 2) ja märkides inoodi muudetuks ja kasutatavaks. Pange tähele viiteid iput() vea radade (error paths) jaoks, et vähendada viidete loendit uues inoodis.

pipe() peab olema kaudu R0 ja R1 tagastama failide deskriptorite numbrid lugemiseks ja kirjutamiseks. falloc() tagastab viite failistruktuurile, kuid ka 'tagastab' läbi u.u_ar0[R0] ja failide deskriptorit. See tähendab, et kood salvestab r failide deskriptor lukemiseks ja määrab kirjutamisekdeskriptori otse u.u_ar0[R0] pärast teist kutsumist falloc().

Lipp FPIPE, mille seadsime konveieri loomisel, juhib funktsiooni rdwr() sys2.c-s, mis kutsub üles konkreetseid sisendi-väljundi alprogrammes 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);
    }
        /* … */
}

Siis funktsioon readp() ühes pipe.c loeb andmeid konveierist. Kuid parim on jälgida rakendust alates writep().Kordan, et kood on muutunud keerulisemaks argumentide edastamise kokkuleppe põhjustel, kuid mõned detailid võib vahele jätta.

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* Kui kõik on tehtud, tagastame. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * Kui torul ei ole samaaegselt lugemist ja kirjutamist,
     * tagastame vea ja anname märku.
     */

    if(ip->i_count i_size1 == PIPSIZ) {
        ip->i_mode |= IWRITE;
        prele(ip);
        sleep(ip + 1, PPIPE);
        goto loop;
    }

    /* Kirjutame, mis on võimalik, ja tuleme tagasi. */

    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;
}

Torusse tahame kirjutada baite u.u_count. Esiteks nõuame indeksdessaatori lukku (vt allpool plock/prele).

Siis kontrollime inode'i viidete loendurit. Niikaua kui mõlemad toru otsad jäävad avatuks, peab loendur olema 2. Me hoiame ühe viite (nagu rp->f_inode), nii et kui loendur on alla 2, siis peab see tähendama, et lugemisprotsess on oma toru otsa sulgenud. Teisisõnu, me üritame kirjutada suletud torusse, mis on viga. Vea kood on esmakordselt EPIPE ja signaal SIGPIPE ilmnes kuues Unix'i versioonis.

Kuid isegi kui toru on avatud, võib see olla täis. Sellel juhul vabastame blokeeringu ja läheme magama lootuses, et teine protsess loeb torust ja vabastab piisavalt ruumi. Kui ärkame, naaseme algusesse, paneme jälle blokeeringu ja käivitame uue kirjutamistsükli.

Kui torus on piisavalt vaba ruumi, kirjutame andmed selle kaudu writei(). Parameeter i_size1 inode'i (tühjas torus võib olla 0) näitab andmete lõppu, mis seal juba on. Kui ruumi on piisavalt, saame toru täita i_size1 kuni PIPESIZ. Seejärel vabastame blokeeringu ja proovime äratada mistahes protsessi, mis ootab võimalust torust lugeda. Naaseme algusesse, et vaadata, kas suutsime kirjutada nii palju baite, kui vaja. Kui ei, siis alustame uut kirjutamistsüklit.

Tavaliselt kasutatakse parameetrit i_mode inode'is õiguste salvestamiseks r, w ja x. Kuid torude puhul märgime kirjutamise või lugemise ootamise mõne protsessi jaoks bitidega IREAD ja IWRITE vastavalt. Protsess seab lipu ja kutsub välja sleep(), ja oodatakse, et tulevikus kutsub mõni muu protsess üles wakeup().

Tõeline maagia toimub sleep() ja wakeup(). Need on ellu viidud slp.c, tuntud kommentaari „Te ei pea seda mõistma” (You are not expected to understand this) all. Õnneks ei pea me koodi mõistma, vaatame lihtsalt mõningaid kommentaare:

/*
 * 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) /* … */

Protsess, mis kutsub sleep() kindla kanali jaoks, võib hiljem olla äratatud teise protsessi poolt, mis kutsub wakeup() sama kanali jaoks. writep(). ja readp() koordineerivad oma tegevust selliste paariliste kutsungite kaudu. Pange tähele, et pipe.c annab alati prioriteedi PPIPE kui kutsutakse sleep(), seega võivad kõik sleep() saatmist signaali kaudu katkestada.

Nüüd on meil kõik, et aru saada funktsioonist 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 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);
}

Selle funktsiooni võib-olla on lihtsam lugeda alt üles. Haru «read and return» kasutatakse tavaliselt, kui torustikus on andmeid. Sel juhul teeme seda readi() loe piisavalt andmeid alates praegusest f_offset lugemisest ja seejärel uuendame vastava nihke väärtust.

Järgneva lugemise ajal on toru tühi, kui lugemise nihke väärtus on jõudnud i_size1 inode'i väärtuseni. Me lähtestame positsiooni 0-le ja proovime äratada mistahes protsessi, mis tahab toru kirjutada. Teame, et kui toru on täis, writep(). on see magama ip+1. Nüüd, kui konveier on tühi, saame selle käivitada, et see jätkaks oma salvestustsüklit.

Kui lugeda pole midagi, siis readp() võib seada lipu IREAD ja jääda magama ip+2.Teame, et see äratatakse writep()., kui konveierisse kirjutatakse mingeid andmeid.

Kommentaarid readi() ja writei() aitavad mõista, et "u" asemel saame nendega käituda nagu tavaliste sisend-väljundfunktsioonidega, mis võtavad faili, positsiooni, mälubufferi ja loevad või kirjutavad baitide arvu.

/*
 * 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;
/* … */

Mis puudutab "konservatiivset" lukustamist, siis readp() ja writep(). lukustavad inode'i kuni töö lõpetamiseni või tulemuse saamiseni (st kuni kutsuvad üles wakeup). plock() ja prele() töötab lihtsalt: teise kutsungite kogumiga uni ja wakeup kõikidesse protsessidesse, mis vajavad just äsja eemaldatud lukku, äratamiseks:

/*
 * 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);
    }
}

Alguses ei saanud ma aru, miks readp() ei kutsu prele(ip) enne wakeup(ip+1). Esimene, mida writep(). kutsutakse üles oma tsüklis, on plock(ip), mis viib ummikusse, kui readp() ta ei ole oma lukku veel eemaldanud, seega peab kood mingil viisil õigesti töötama. Kui vaadata wakeup(), siis saab selgeks, et see vaid märgib magava protsessi kui täitmiseks valmis, et tulevikus sched() tõepoolest käivitas selle. Nii et readp() kutsub wakeup(), eemaldab lukustuse, määrab IREAD ja kutsub sleep(ip+2)— kõik see enne, kui writep(). taas alustab tsüklit.

Sellega on kuue versiooni kanalite kirjeldamine lõppenud. Lihtne kood, kaugeleulatuvad tagajärjed.

Seitsmes versioon Unix’ist (jaanuar 1979) oli uus peamine väljaanne (neli aastat hiljem), milles ilmus palju uusi rakendusi ja tuuma omadusi. Samuti toimusid selles olulised muudatused seoses tüübivalimise, liitude ja tüübitud näidikute kasutamisega struktuuride osas. Siiski kanalite kood praktiliselt ei muutunud. Võime selle väljaande vahele jätta.

Xv6, lihtne Unix-tüüpi tuum

Xv6 tuuma loomine Xv6 Unix'i kuues versioon mõjutas seda, kuid see on kirjutatud modernses C-s, et seda saaks käitada x86 protsessoritel. Kood on kergesti loetav ja arusaadav. Lisaks, erinevalt Unix'i algkoodist TUHS-is, saate selle kompileerida, muuta ja käitada midagi muud peale PDP 11/70. Seetõttu kasutatakse tuuma laialdaselt ülikoolides õppetöös operatsioonisüsteemide teemal. Algkood asub Githubis.

Kood sisaldab arusaadavat ja hoolikalt läbi mõeldud rakendust pipe.c, toetatud mälupuhvriga asemel inode'ist kettal. Siin tooin ainult „struktuurse toru“ määratluse ja funktsioonid 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() määrab seisundi kogu ülejäänud rakendusele, mis sisaldab funktsioone piperead(), pipewrite() ja pipeclose(). Tegelik süsteemi kõne sys_pipe on ümbris, mille on rakendanud sysfile.c. Soovitan lugeda kogu selle koodi. Raskusaste on kuues versioon, kuid lugeda on see märksa kergem ja meeldivam.

Linux 0.01

Algkoodi Linux 0.01 võib leida. On hariv uurida torude rakendust selle fs/pipe.c. Siin kasutatakse toru esitlemiseks inode'i, kuid toru on kirjutatud modernses C-s. Kui olete kuues versioonis koodi läbi uurinud, siis ei tohiks teil siin raskusi olla. Nii näeb välja funktsioon 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) { /* lugejat pole */
        current->signal |= (1<0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<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;
}

Isegi struktuuride määratlemata jätmist on võimalik mõista, kuidas inode'i viidete loendit kasutatakse, et kontrollida, kas kirjutamine SIGPIPE. Lisaks bite-by-bite tööle on selle funktsiooni lihtne seostada eespool kirjeldatud ideedega. Isegi loogika sleep_on/wake_up ei tundu nii võõras.

Kaasaegsed Linuxi tuumad, FreeBSD, NetBSD, OpenBSD

Kiirelt vaatasin üle mõned kaasaegsed tuumad. Üheski neist ei ole enam rakendust, mis kasutaks ketast (mis pole üllatav). Linuxil on oma rakendus. Ja kuigi kolm kaasaegset BSD tuuma sisaldavad rakendusi, mis põhinevad John Dysoni kirjutatud koodil, on nad aastate jooksul üksteisest liiga palju erinevaks muutunud.

Lugemiseks fs/pipe.c (Linuxis) või sys/kern/sys_pipe.c (BSD peal) on tõeline pühendumine vajalik. Täna on koodis olulised jõudlus ja toetatud funktsioonid, nagu vektoriaalsed ja asünkroonsed sisend-väljundoperatsioonid. Ja mäluhaldamise, lukustamise ja tuuma konfiguratsiooni üksikasjad - kõik see varieerub väga. See ei ole midagi, mida kõrgharidusasutused vajavad operatsioonisüsteemide sissejuhatavaks kursuseks.

Igatahes, oli huvitav kaevuda välja mõned vanad mustrid (näiteks, genereerimine SIGPIPE ja tagastamine EPIPE sulgemise toru kirjutamisel) kõigis nendes, nii erinevates, kaasaegsetes tuumades. Tõenäoliselt ma ei näe kunagi PDP-11 arvutit elus, kuid koodist, mis on kirjutatud aastatel enne minu sündi, on ikka veel palju õppida.

Divi Kapuri 2011. aastal kirjutatud artikkel "Linuxi kernel’i torustiku ja FIFO-de rakendamine» annab ülevaate, kuidas (siiani) torustikud Linuxis töötavad. Ja hiljutine commi Linuxis ilustrib torustiku mudelit, mille võimalused ületavad ajutiste failide omadusi; ning näitab, kui kaugele on torustikud jõudnud «väga konservatiivsest lukustusest» Unix 6. väljaandes.

Allikas: habr.com