Како се имплементираат цевководи во Unix

Оваа статија ја опишува имплементацијата на цевководи во кернелот Unix. Бев малку разочаран што неодамнешната статија со наслов „Како работат нафтоводите во Unix?» испадна Нема за внатрешната структура. Се заинтересирав и копав во старите извори за да го најдам одговорот.

За што зборуваме?

Цевководите се „веројатно најважниот изум во 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) мора да бидат атомски за процесите да можат да комуницираат едни со други преку цевководот на начин на кој нормалните датотеки (кои не даваат такви гаранции) не можат.

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

Што бараме?

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

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

Каде бараме?

Не знам каде се наоѓа мојот примерок од познатата книга.Лавови книга« со изворниот код на Unix 6, но благодарение на Друштвото за наследство на Уникс може да се пребарува на интернет изворен код дури и постари верзии на Unix.

Талкањето низ архивите на TUHS е како посета на музеј. Можеме да ја погледнеме нашата заедничка историја и имам почит за годините напор да го повратам целиот овој материјал малку по малку од старите касети и отпечатоци. И јас сум акутно свесен за оние фрагменти што сè уште недостасуваат.

Откако ја задоволивме нашата љубопитност за античката историја на цевководи, можеме да ги погледнеме модерните јадра за споредба.

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

Традиционални Unix кернели (1970–1974)

Не најдов никаква трага pipe(2) ниту во PDP-7 Unix (јануари 1970), ниту во прво издание Unix (ноември 1971), ниту во нецелосен изворен код второ издание (јуни 1972).

ТУХС го тврди тоа трето издание Unix (февруари 1973 година) беше првата верзија со цевководи:

Третото издание на Unix беше последната верзија со кернел напишано во асемблер, но и првата верзија со цевководи. Во текот на 1973 година, се работеше за подобрување на третото издание, кернелот беше препишан во C и така се роди четвртото издание на Unix.

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

Во книгата на Брајан КерниганUnix: Историја и мемоари“, историјата на појавата на транспортери го споменува и овој документ: „... 30 години висеше на ѕидот во мојата канцеларија во Bell Labs“. Еве интервју со Мекилроји уште една приказна од Делото на Мекилрој, напишано во 2014 година:

Кога се појави Unix, мојата страст за корутини ме натера да побарам од авторот на ОС, Кен Томпсон, да дозволи податоците запишани во некој процес да одат не само до уредот, туку и до излезот од друг процес. Кен мислеше дека тоа е можно. Сепак, како минималист, тој сакаше секоја карактеристика на системот да игра значајна улога. Дали директното пишување помеѓу процесите навистина е голема предност во однос на пишувањето во средна датотека? И дури кога дадов конкретен предлог со привлечното име „цевковод“ и опис на синтаксата на интеракцијата на процесите, Кен конечно извика: „Ќе го направам тоа!“.

И направи. Една судбоносна вечер, Кен ги смени кернелот и школка, поправи неколку стандардни програми за да го стандардизира начинот на прифаќање на влезот (што може да дојде од гасоводот) и ги смени имињата на датотеките. Следниот ден, цевководите беа многу широко користени во апликациите. До крајот на неделата, секретарите ги користеа за да испраќаат документи од процесори на текст до печатачот. Нешто подоцна, Кен ги замени оригиналниот API и синтаксата за завиткување на употребата на цевководи со почисти конвенции кои оттогаш се користат.

За жал, изворниот код за третото издание Unix кернелот е изгубен. И иако го имаме изворниот код на јадрото напишан во C четврто издание, кој беше објавен во ноември 1973 година, но излезе неколку месеци пред официјалното објавување и не содржи имплементација на цевководи. Штета што изворниот код за оваа легендарна функција на Unix е изгубен, можеби засекогаш.

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

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

До следната година, кернелот беше препишан во C, и цевка (2) во четврто издание го стекна својот модерен изглед со прототипот "pipe(fildes)"

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

Се претпоставува дека штом ќе се дефинира гасоводот, два (или повеќе) интерактивни процеси (создадени со последователни повикувања вилушка) ќе пренесува податоци од гасоводот користејќи повици чита и пишувам.

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

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

Најрано зачувана имплементација на гасоводот се однесува до петтото издание на Unix (јуни 1974), но е речиси идентичен со оној што се појави во следното издание. Додадени се само коментари, така што петтото издание може да се прескокне.

Шестото издание на Unix (1975)

Почнува да го чита изворниот код на Unix шесто издание (мај 1975). Во голема мера благодарение на Лавови многу е полесно да се најде од изворите на претходните верзии:

За многу години книгата Лавови беше единствениот документ на Unix кернелот достапен надвор од Bell Labs. Иако лиценцата за шестото издание им дозволуваше на наставниците да го користат нејзиниот изворен код, лиценцата за седмото издание ја исклучи оваа можност, па книгата беше дистрибуирана во нелегални копии на машина.

Денес можете да купите препечатен примерок од книгата, чија корица ги прикажува студентите на копир. И благодарение на Ворен Томи (кој го започна проектот TUHS), можете да преземете Шестото издание Извор PDF. Сакам да ви дадам идеја за тоа колку напор се вложи во креирањето на датотеката:

Пред повеќе од 15 години, напишав копија од изворниот код наведен во Лавовизатоа што не ми се допадна квалитетот на мојата копија од непознат број други копии. TUHS сè уште не постоеше, а јас немав пристап до старите извори. Но, во 1988 година најдов стара лента со 9 песни на кои имало резервна копија од компјутер PDP11. Тешко беше да се знае дали работи, но имаше недопрено дрво /usr/src/ во кое повеќето датотеки беа означени 1979 година, што дури и тогаш изгледаше античко. Тоа беше седмото издание, или дериват на PWB, си помислив.

Го зедов наодот како основа и рачно ги уредив изворите до состојбата на шестото издание. Дел од кодот остана ист, дел мораше малку да се уреди, менувајќи го модерниот токен += во застарен =+. Нешто едноставно беше избришано, и нешто требаше целосно да се преработи, но не премногу.

И денес можеме да го прочитаме онлајн на TUHS изворниот код на шестото издание на архива, во која имаше рака Денис Ричи.

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

Почетокот /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 user u» и се запишува R0 и R1 се пренесуваат параметрите на системскиот повик и повратните вредности.

Ајде да се обидеме со ialloc() место на дискот инода (инода), и со помош falloc () - продавница два датотека. Ако се оди добро, ќе поставиме знаменца за да ги идентификуваме овие датотеки како двата краја на гасоводот, ќе ги насочиме кон истата инода (чиј број на референци станува 2) и ќе ја означиме инодата како изменета и во употреба. Обрнете внимание на барањата за ставам() во патеките на грешки за да се намали бројот на референци во новата инода.

pipe() се должи преку R0 и R1 вратете ги броевите на дескрипторот на датотеките за читање и пишување. falloc() враќа покажувач во структура на датотека, но и „враќа“ преку u.u_ar0[R0] и дескриптор на датотека. Тоа е, кодот е зачуван во r дескриптор на датотека за читање и доделува дескриптор за пишување директно од 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. Прво треба да ја заклучиме инодата (види подолу plock/prele).

Потоа го проверуваме бројот на референци на инода. Сè додека двата краја на цевководот останат отворени, бројачот треба да биде 2. Се држиме за една врска (од rp->f_inode), па ако бројачот е помал од 2, тогаш тоа треба да значи дека процесот на читање го затворил својот крај на гасоводот. Со други зборови, се обидуваме да пишеме на затворен гасовод, што е грешка. Првиот код за грешка EPIPE и сигнал SIGPIPE се појави во шестото издание на Unix.

Но, дури и ако транспортерот е отворен, може да биде полн. Во овој случај, ја ослободуваме бравата и одиме да спиеме со надеж дека друг процес ќе прочита од гасоводот и ќе ослободи доволно простор во него. Кога ќе се разбудиме, се враќаме на почетокот, повторно ја закачуваме бравата и започнуваме нов циклус на пишување.

Ако има доволно слободен простор во цевководот, тогаш запишуваме податоци на него користејќи writei (). Параметар 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()кога ќе запише некои податоци на гасоводот.

Коментари на 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() заклучете ги инодите додека не завршат или не добијат резултат (т.е. повикајте 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, едноставно јадро слично на Unix

Да се ​​создаде јадро Xv6 под влијание на шестото издание на Unix, но напишано во модерна C за да работи на x86 процесори. Кодот е лесен за читање и разбирлив. Исто така, за разлика од изворите на Unix со 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.в. Препорачувам да го прочитате целиот негов код. Комплексноста е на ниво на изворниот код на шестото издание, но е многу полесен и попријатен за читање.

Linux 0.01

Можете да го најдете изворниот код за Linux 0.01. Ќе биде поучно да се проучува имплементацијата на цевководи во неговата fs/pipe.c. Овде, инода се користи за претставување на гасоводот, но самиот гасовод е напишан во модерна C. Ако сте го пробиле кодот на шестото издание, нема да имате никакви проблеми овде. Вака изгледа функцијата write_pipe():

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

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

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

Модерни Linux кернели, FreeBSD, NetBSD, OpenBSD

Набрзина преминав на некои модерни кернели. Ниту еден од нив веќе нема имплементација базирана на диск (не е изненадувачки). Линукс има своја имплементација. И иако трите модерни BSD кернели содржат имплементации базирани на код што го напиша Џон Дајсон, со текот на годините тие станаа премногу различни едни од други.

Да чита fs/pipe.c (на Линукс) или sys/kern/sys_pipe.c (на *BSD), потребна е вистинска посветеност. Перформансите и поддршката за функции како што се векторски и асинхрони I/O се важни во кодот денес. И деталите за распределбата на меморијата, бравите и конфигурацијата на кернелот се многу различни. Ова не е она што им е потребно на универзитетите за воведен курс за оперативни системи.

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

Напишано од Диви Капур во 2011 година, написот „Имплементација на кернелот на Linux на цевки и FIFOе преглед на тоа како функционираат нафтоводите на Линукс (досега). А неодамнешно извршување на Линукс го илустрира моделот на интеракција на гасоводот, чии можности ги надминуваат оние на привремените датотеки; и исто така покажува колку далеку отишле цевководите од „многу конзервативното заклучување“ во шестото издание на Unix кернелот.

Извор: www.habr.com