Како се цевоводи имплементирају у Уник-у

Овај чланак описује имплементацију цевовода у Уник кернелу. Био сам помало разочаран што је недавни чланак под насловом "Како цевоводи функционишу у Унику?"Испоставило се не о унутрашњој структури. Постао сам радознао и копао сам по старим изворима да пронађем одговор.

Шта говоримо?

Цевоводи, „вероватно најважнији проналазак у Уник-у,” су дефинишућа карактеристика основне Уник филозофије повезивања малих програма заједно, као и познати знак на командној линији:

$ 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 и 4 да би се ускладили са стдин и стдоут.

Без цеви, љуска би морала да запише резултат једног процеса у датотеку и проследи га другом процесу да прочита податке из датотеке. Као резултат тога, трошили бисмо више ресурса и простора на диску. Међутим, цевоводи су добри не само зато што вам омогућавају да избегнете употребу привремених датотека:

Ако процес покушава да чита из празног цевовода онда read(2) ће блокирати док подаци не постану доступни. Ако процес покуша да упише у цео цевовод, онда write(2) ће блокирати све док се из цевовода не прочита довољно података за уписивање.

Као и захтев ПОСИКС, ово је важно својство: писање у цевовод до PIPE_BUF бајтови (најмање 512) морају бити атомски како би процеси могли да комуницирају једни са другима кроз цевовод на начин на који обични фајлови (који не пружају такве гаранције) не могу.

Када се користи обична датотека, процес може записати сав свој излаз у њега и проследити га другом процесу. Или процеси могу да раде у веома паралелном режиму, користећи спољни механизам сигнализације (попут семафора) да обавештавају једни друге када се уписивање или читање заврши. Транспортери нас спасавају од свих ових проблема.

Шта тражимо?

Објаснићу то једноставним речима тако да вам буде лакше да замислите како транспортер може да функционише. Мораћете да доделите бафер и неко стање у меморији. Биће вам потребне функције за додавање и уклањање података из бафера. Биће вам потребна нека средства за позивање функција током операција читања и писања на дескрипторима датотека. И биће вам потребне браве да бисте применили посебно понашање описано изнад.

Сада смо спремни да испитамо изворни код кернела под јаким светлом лампе да бисмо потврдили или оповргли наш нејасан ментални модел. Али увек будите спремни на неочекивано.

Где тражимо?

Не знам где је мој примерак чувене књиге“Књига о лавовима„са Уник 6 изворним кодом, али захваљујући Уник Херитаге Социети можете претраживати на мрежи на изворни код чак и старије верзије Уника.

Лутање кроз ТУХС архиве је као посета музеју. Можемо да погледамо нашу заједничку историју, и поштујем дугогодишње напоре да се сав овај материјал по мало поврати са старих трака и отисака. И веома сам свестан тих фрагмената који још увек недостају.

Пошто смо задовољили нашу радозналост о древној историји транспортера, можемо да погледамо модерна језгра за поређење.

Узгред, pipe је системски позив број 42 у табели sysent[]. Случајност?

Традиционална Уник језгра (1970–1974)

Нисам нашао никакве трагове pipe(2) ni u ПДП-7 Уник (јануар 1970), ни у прво издање Уник-а (новембар 1971), нити у непотпуном изворном коду друго издање (јун 1972).

ТУХС то наводи треће издање Уник-а (фебруар 1973) постала је прва верзија са покретним тракама:

Уник 1973рд Едитион је била последња верзија са кернелом написаним на асемблерском језику, али и прва верзија са цевоводима. Током XNUMX. године радило се на побољшању трећег издања, кернел је преписан у Ц, и тако се појавило четврто издање Уника.

Један читалац је пронашао скенирани документ у којем је Даг Мекилрој предложио идеју „повезивања програма попут баштенског црева“.

У књизи Брајана КерниганаУник: Историја и мемоари“, у историји настанка транспортера помиње се и овај документ: „... висио је на зиду у мојој канцеларији у Белл Лабс-у 30 година.” Ево интервју са Мекилројем, и још једна прича из Мекилројево дело, написано 2014:

Када се појавио Уник, моја фасцинација корутинама ме је навела да замолим аутора ОС-а, Кена Томпсона, да дозволи да подаци уписани у процес иду не само на уређај, већ и да излазе у други процес. Кен је одлучио да је то могуће. Међутим, као минималиста, желео је да свака функција система игра значајну улогу. Да ли је писање директно између процеса заиста велика предност у односу на писање у посредни фајл? Тек када сам дао конкретан предлог са привлачним називом „цевовод“ и описом синтаксе за интеракцију између процеса, Кен је коначно узвикнуо: „Урадићу то!“

И јесте. Једне кобне вечери, Кен је променио кернел и љуску, поправио неколико стандардних програма како би стандардизовао начин на који прихватају унос (који би могао да дође из цевовода), а такође је променио имена датотека. Следећег дана, цевоводи су почели да се веома широко користе у апликацијама. До краја недеље, секретарице су их користиле за слање докумената из програма за обраду текста у штампач. Нешто касније, Кен је заменио оригинални АПИ и синтаксу за умотавање употребе цевовода чистијим конвенцијама, које се од тада користе.

Нажалост, изворни код за треће издање Уник кернела је изгубљен. И иако имамо изворни код кернела написан у Ц четврто издање, објављен у новембру 1973. године, али је изашао неколико месеци пре званичног објављивања и не садржи имплементације цевовода. Штета што је изворни код за ову легендарну Уник функцију изгубљен, можда заувек.

Имамо текстуалну документацију за pipe(2) из оба издања, тако да можете почети претраживањем документације треће издање (за одређене речи, подвучено „ручно“, низ литерала ^Х, након чега следи доња црта!). Овај прото-pipe(2) је написан у асемблерском језику и враћа само један дескриптор датотеке, али већ пружа очекивану основну функционалност:

Системски позив цев ствара улазно/излазни механизам који се назива цевовод. Враћени дескриптор датотеке може се користити за операције читања и писања. Када се нешто упише у цевовод, баферује се до 504 бајта података, након чега се процес писања суспендује. Приликом читања из цевовода, баферовани подаци се одузимају.

До следеће године језгро је преписано у Ц, и пипе(2) у четвртом издању добио свој модеран изглед са прототипом"pipe(fildes)"

Системски позив цев ствара улазно/излазни механизам који се назива цевовод. Дескриптори враћених датотека могу се користити у операцијама читања и писања. Када се нешто упише у цевовод, користи се ручка враћена у р1 (односно филдес[1]), баферована на 4096 бајтова података, након чега се процес писања суспендује. Приликом читања из цевовода, ручица враћена на р0 (односно филдес[0]) преузима податке.

Претпоставља се да када је цевовод дефинисан, два (или више) комуникационих процеса (креирани накнадним позивима ка виљушка) ће пренети податке из цевовода помоћу позива читати и write (писати).

Схелл има синтаксу за дефинисање линеарног низа процеса повезаних цевоводом.

Позиви за читање из празног цевовода (који не садржи бафероване податке) који има само један крај (сви дескриптори датотеке за писање су затворени) враћају „крај датотеке“. Позиви на писање у сличној ситуацији се игноришу.

Најраније очувана имплементација цевовода односи се до петог издања Уник-а (јун 1974), али је скоро идентична оној која се појавила у следећем издању. Коментари су управо додати, тако да можете прескочити пето издање.

Шесто издање Уника (1975)

Почнимо да читамо Уник изворни код шесто издање (мај 1975). У великој мери захваљујући Знаменитости много је лакше пронаћи него изворе ранијих верзија:

Дуги низ година књига Знаменитости је био једини документ о Уник кернелу доступан ван Белл Лабс-а. Иако је лиценца шестог издања омогућавала наставницима да користе њен изворни код, лиценца седмог издања је искључила ову могућност, па је књига дистрибуирана у облику илегалних куцаних копија.

Данас можете купити репринт књиге на чијим корицама су ученици за фотокопир машином. И захваљујући Ворену Тоомију (који је започео пројекат ТУХС) можете преузети ПДФ датотека са изворним кодом за шесто издање. Желим да вам дам представу о томе колико је труда уложено у креирање датотеке:

Пре више од 15 година, откуцао сам копију датог изворног кода Знаменитости, јер ми се није допао квалитет мог примерка из непознатог броја других примерака. ТУХС још није постојао и нисам имао приступ старим изворима. Али 1988. пронашао сам стару траку са 9 трака која је садржала резервну копију са ПДП11 рачунара. Било је тешко рећи да ли ради, али постојало је нетакнуто /уср/срц/ стабло у којем је већина фајлова означена са годином 1979, која је чак и тада изгледала древно. Било је то седмо издање или његов дериват ПВБ, како сам веровао.

Узео сам налаз као основу и ручно уредио изворе до шестог издања. Неки од кодова су остали исти, али су неки морали бити мало измењени, мењајући модерни токен += у застарели =+. Неке ствари су једноставно обрисане, а неке су морале бити потпуно преписане, али не превише.

А данас можемо да читамо онлајн на ТУХС изворни код шестог издања од архиву, којој је руку имао Денис Ричи.

Иначе, на први поглед, главна карактеристика Ц-кода пре периода Кернигана и Ричија је његова краткоћа. Није често да могу да убацим делове кода без опсежног уређивања како би се уклопио у релативно уско подручје приказа на мојој веб локацији.

Рано /уср/сис/кен/пипе.ц постоји коментар са објашњењем (и да, има их још /уср/сис/дмр):

/*
 * 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, који постављамо приликом креирања цевовода, контролише понашање функције рдвр() у сис2.цпозивање специфичних И/О рутина:

/*
 * 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 иноде (ако је цевовод празан, може бити једнак 0) означава крај података које већ садржи. Ако има довољно простора за снимање, можемо да напунимо цевовод из i_size1 до PIPESIZ. Затим отпуштамо закључавање и покушавамо да пробудимо било који процес који чека на читање са цевовода. Враћамо се на почетак да видимо да ли смо у стању да запишемо онолико бајтова колико нам је потребно. Ако не успе, почињемо нови циклус снимања.

Обично параметар i_mode иноде се користи за чување дозвола 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„Можемо их третирати као нормалне И/О функције које узимају датотеку, позицију, бафер у меморији и броје број бајтова за читање или писање.

/*
 * 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.) је било ново велико издање (четири године касније) које је увело многе нове апликације и карактеристике кернела. Такође је претрпео значајне промене у вези са коришћењем ливења типа, спојева и куцаних показивача на структуре. Међутим код транспортера практично непромењена. Можемо прескочити ово издање.

Ксв6, једноставно језгро слично Унику

За креирање кернела Ксв6 под утицајем шестог издања Уник-а, али је написано у модерном Ц-у да ради на к86 процесорима. Код је лак за читање и разумљив. Плус, за разлику од Уник извора са ТУХС-ом, можете га компајлирати, модификовати и покренути на нечему другом осим на ПДП 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. Биће поучно проучити имплементацију цевовода у његовом fs/pipe.c. Ово користи иноде за представљање цевовода, али сам цевовод је написан у модерном Ц. Ако сте радили свој пут кроз код XNUMX. издања, овде нећете имати проблема. Овако изгледа функција write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

Чак и не гледајући дефиниције структуре, можете схватити како се број референци инода користи за проверу да ли операција писања резултира SIGPIPE. Поред рада бајт по бајт, ову функцију је лако упоредити са горе описаним идејама. Чак и логика sleep_on/wake_up не изгледа тако страно.

Модерни Линук кернели, ФрееБСД, НетБСД, ОпенБСД

Брзо сам прошао кроз неке модерне кернеле. Нико од њих више нема имплементацију диска (није изненађујуће). Линук има своју имплементацију. Иако три модерна БСД језгра садрже имплементације засноване на коду који је написао Џон Дајсон, током година су постали превише различити један од другог.

Читати fs/pipe.c (на Линук-у) или sys/kern/sys_pipe.c (на *БСД), потребна је права посвећеност. Данашњи код се односи на перформансе и подршку за функције као што су векторски и асинхрони И/О. А детаљи расподеле меморије, закључавања и конфигурације кернела веома се разликују. Ово није оно што је потребно колеџима за уводни курс оперативних система.

У сваком случају, био сам заинтересован да ископам неке старе обрасце (као што је генерисање SIGPIPE и повратак EPIPE при писању у затворени цевовод) у свим овим различитим модерним језгрима. Вероватно никада нећу видети рачунар ПДП-11 у стварном животу, али још увек има много тога да се научи из кода који је написан годинама пре мог рођења.

Чланак који је написао Диви Капоор 2011:Имплементација цеви и ФИФО-ова Линук кернела" пружа преглед како цевоводи (још увек) функционишу у Линук-у. А недавно урезивање у Линуку илуструје цевоводни модел интеракције, чије могућности превазилазе оне привремених датотека; и такође показује колико су цевоводи отишли ​​од "веома конзервативног закључавања" шестог издања Уник кернела.

Извор: ввв.хабр.цом