Как са реализирани конвейерите в Unix

В тази статия е описана реализация на конвейерите в ядрото на Unix. Бях малко разочарован, че наскоро публикуваната статия с името „Как работят конвейерите в Unix?“ се оказа не за вътрешната структура. Заинтересувах се и копнах в стари източници, за да намеря отговора.

За какво става дума?

Конвейерите — „вероятно най-важното изобретение в Unix“ — са определяща характеристика на основната философия на Unix за обединяване на малки програми, а също и познатата надпис в командния ред:

$ echo hello | wc -c
6

Тази функционалност зависи от системния повик, предоставен от ядрото, pipeкойто е описан в документацията на pipe(7) и pipe(2):

Конвейерите предоставят еднопосочен канал за междупроцесно взаимодействие. Конвейерът има вход (write end) и изход (read end). Данни, записани на входа на конвейера, могат да бъдат прочетени на изхода.

Конвейерът се създава с помощта на повикването 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(), за да получи свързаните файлови дескриптори. Един от дочерните процеси записва в един дескриптор, докато друг процес прочита същите данни от друг дескриптор. Обвивката с помощта на dup2 „преименува“ дескрипторите 3 и 4, за да съответстват на stdin и stdout.

Без конвейерите обвивката щеше да записва резултата на един процес в файл и да предава на друг процес, за да прочете данните от файла. Това би довело до по-голямо използване на ресурси и дисково пространство. Но конвейерите не са полезни само за избягване на временни файлове:

Ако процесът се опита да прочете от празен конвейер, тогава read(2) ще блокира, докато данните не станат налични. Ако процесът опита да запише в пълен конвейер, тогава write(2) ще бъде блокиран, докато не бъдат прочетени достатъчно данни от конвейера, за да се извърши запис.

Както изисква POSIX, това е важно свойство: записът в конвейера до PIPE_BUF байтове (поне 512) трябва да бъде атомарен, за да могат процесите да взаимодействат помежду си чрез конвейера по начин, по който обикновените файлове (които не предоставят такива гаранции) не могат.

При използване на обикновен файл процесът може да запише всичките си изходни данни и да ги предаде на друг процес. Или процесите могат да действат в режим на строга паралелност, използвайки външен сигнален механизъм (като семафор), за да уведомят един друг за приключване на записването или четенето. Конвейерите ни освобождават от всичките тези затруднения.

Какво търсим?

Ще обясня на примери, за да ви е по-лесно да си представите как може да работи конвейерът. Ще ви е необходим буфер в паметта и някакво състояние. Ще са нужни функции за добавяне и премахване на данни от буфера. Нужен е и инструмент, който да извиква функции по време на операции по четене и запис в файловите дескриптори. И ще са нужни блокировки, за да реализираме споменатото горе специфично поведение.

Сега сме готови да изследваме при ярка светлина лампите изходния код на ядрото, за да потвърдим или опровергаем нашата неясна умствена модел. Но винаги бъдете готови за изненади.

Къде търсим?

Не знам къде се намира моят екземпляр на известната книга "Lions book" с изходния код на Unix 6, но благодарение на The Unix Heritage Society можем да потърсим онлайн в изходния код на още по-старите версии на Unix.

Блуждаенето из архивите на TUHS е подобно на посещение на музей. Можем да погледнем в нашата обща история и чувствам респект към многогодишните усилия за възстановяване на всички тези материали бит по бит от стари касетки и печати. И остра осъзнавам липсващите фрагменти.

Удовлетворявайки любопитството си относно древната история на конвейерите, можем за сравнение да погледнем на съвременните ядра.

Между другото, pipe е системен повик номер 42 в таблицата sysent[]. Случайност?

Традиционни ядра на Unix (1970–1974)

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

TUHS твърди, че третото издание на Unix (февруари 1973) беше първата версия с канали:

Третата редакция на Unix беше последната версия с ядро, написано на асемблер, но и първата версия с канали. През 1973 година се работеше по подобряване на третата редакция, ядро беше пренаписано на C, и така се появи четвъртата версия на Unix.

Един от читателите намери скан на документ, в който Даг МакИлрой предложи идеята за "свързване на програми по принципа на градинския маркуч".

В книгата на Брайън Керниган "Unix: История и мемоари" също се споменава този документ: "... той висеше на стената в офиса ми в Bell Labs в продължение на 30 години". Ето интервю с МакИлрой, и още една история от работата на МакИлрой, написана през 2014:

Когато се появи Unix, моят интерес към корутините ме накара да попитам автора на ОС, Кен Томпсън, да позволи на данните, записани в някакъв процес, да отиват не само на устройството, но и на изхода към друг процес. Кен реши, че това е възможно. Въпреки това, като минималист, той искаше всяка системна функция да играе значителна роля. Наистина ли директното записване между процесите е с голямо предимство в сравнение с записването в междинен файл? И само когато представих конкретно предложение с привлекателното име "канал" и описание на синтаксиса за взаимодействие между процесите, Кен най-накрая възкликна: "Ще го направя!".

И той го направи. В една съдбоносна вечер Кен промени ядрото и обвивката, поправи няколко стандартни програми, стандартизирайки техния процес на приемане на входни данни (които могат да идват от канали), а също така промени имената на файловете. На следващия ден каналите започнаха да се прилагат много широко в приложенията. До края на седмицата секретарките ги използваха, за да изпращат документи от текстови редактори на принтера. Няколко по-късно Кен замени оригиналния API и синтаксиса за обвивката на канали с по-чисти споразумения, които оттогава се прилагат.

За съжаление, изходният код на ядрото на третата редакция на Unix е загубен. И въпреки че имаме написан на C изходен код на ядрото на четвъртата редакция, която излезе през ноември 1973, тя излезе няколко месеца преди официалното издание и не съдържа реализация на каналите. Жалко е, че изходният код на легендарната функция на Unix е загубен, може би завинаги.

Имаме текст на документацията за pipe(2) и от двете издания, така че можем да започнем с търсене в документацията третото издание (по определени думи, подчертавани „ръчно“, ред с литерали ^H, след който следва долна черта!). Този прототипpipe(2) е написан на асемблер и връща само един файлов дескриптор, но вече предоставя очакваната основна функционалност:

Системно повикване pipe създава механизъм за вход-изход, наречен конвейер. Върнатият файлов дескриптор може да се използва за операции по четене и писане. Когато нещо се запише в конвейера, то се буферира до 504 байта данни, след което процесът на запис се спира. При четене от конвейера, буферираните данни се взимат.

До следващата година ядрото беше презаписано на C, а pipe(2) в четвъртото издание придоби съвременния си вид с прототипа „pipe(fildes)»:

Системно повикване pipe създава механизъм за вход-изход, наречен конвейер. Върнатите файлови дескриптори могат да се използват при операции по четене и писане. Когато нещо се записва в конвейера, се използва дескрипторът, върнат в r1 (съответства на fildes[1]), който се буферира до 4096 байта данни, след което процесът на запис се спира. При четене от конвейера, дескрипторът, върнат в r0 (съответства на fildes[0]), взима данни.

Предполага се, че след определянето на конвейера два (или повече) взаимодействуващи процеса (създадени от последващи повиквания fork) ще предават данни от конвейера с помощта на повиквания read и write.

В шел има синтаксис за определяне на линейен масив от процеси, свързани чрез конвейер.

Повикванията за четене от празен конвейер (който не съдържа буферирани данни), който има само един край (записващите файлови дескриптори са затворени), връщат „край на файла“. Повикванията за запис в аналогична ситуация се игнорират.

Най-ранната оцеляла реализация на конвейер се отнася към петото издание на Unix (юни 1974 г.), но е почти идентична на тази, която се появи в следващото издание. Само добавиха коментари, така че петото издание може да се пропусне.

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

Започваме да четем изходния код на Unix шестото издание (май 1975 г.). До голяма степен благодарение на Lions е много по-лесно да го намерим, отколкото изходните файлове на по-ранни версии:

Много години книгата Lions беше единственият документ за ядрото на Unix, достъпен извън стените на Bell Labs. Въпреки че лицензията на шестата редакция позволяваше на преподавателите да използват изходния код, лицензията на седмата редакция изключи тази възможност, поради което книгата се разпространяваше под формата на нелегални машинописни копия.

Днес можете да закупите репринтно издание на книгата, на корицата на която са изобразени студенти при копирна машина. А благодарение на Уорън Туми (който стартира проекта TUHS) можете да изтеглите PDF файл с изходния код на шестата редакция. Искам да ви дам представа колко усилия са били положени за създаването на файла:

Преди повече от 15 години написах копие на изходния код, изложен в Lions, защото не ми харесваше качеството на копието ми от неизвестен брой други копия. 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, който се използва от «алгоритъма за голямо адресиране» за обработка косвени (indirect) блокове с цел да поддържа по-големи файлови системи. След като Кен каза, че е по-добре да не ги използваме, с радост ще му повярвам.

Ето истински системен повик. 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() — да разположим в паметта два файла. Ако всичко мине добре, ще зададем флагове, за да определим тези файлове като два края на конвейера, ще ги посочим в същия inode (чийто брой на препратки ще стане 2) и ще маркираме inode като променен и използван. Обърнете внимание на обращенията към iput() в грешни пътища (error paths), за да намалим броя на препратките в новия inode.

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)
{
    регистър *rp, *ip, c;

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

loop:
    /* Ако всичко е готово, върнете. */

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

    /*
     * Ако не и двете прочетени и записващи страни на
     * тръбата са активни, върнете грешка и сигнализирайте също.
     *//

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

    /* Запишете каквото е възможно и се върнете обратно. */

    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).

След това проверяваме броя на inode връзките. Докато и двата края на конвейера остават отворени, броячът трябва да е равен на 2. Държим една връзка (от rp->f_inode), така че ако броячът е по-малък от 2, това означава, че процесът за четене е затворил своя край на конвейера. С други думи, опитваме се да пишем в затворен конвейер, което е грешка. Кодът на грешката EPIPE и сигналът SIGPIPE появиха се в шестото издание на Unix.

Но дори и да е отворен, конвейерът може да бъде запълнен. В този случай сваляме блокировката и отиваме да спим в надеждата, че друг процес ще прочете от конвейера и ще освободи достатъчно място. Събудявайки се, се връщаме в началото, отново слагаме блокировка и стартираме нов цикъл на запис.

Ако в конвейера има достатъчно свободно място, записваме данни чрез writei(). Параметър i_size1 на inode-a (това може да е равно на 0 при празен конвейер) указва на края на данните, които вече се съдържат в него. Ако има достатъчно място за запис, можем да напълним конвейера от i_size1 до PIPESIZ. След това сваляме блокировката и опитваме да приведем в състояние на будност всеки процес, който чака възможност да прочете от конвейера. Връщаме се в началото, за да видим дали сме успели да запишем толкова байтове, колкото ни бяха нужни. Ако не успеем, започваме нов цикъл на запис.

Обикновено параметърът i_mode на inode-a се използва за съхраняване на разрешенията r, w и x. Но в случая с конвейерите сигнализираме за изчакването от определен процес, който записва или чете, с помощта на битовете IREAD и IWRITE съответно. Процесът задава флага и извиква sleep(), и се очаква, че в бъдеще друг процес ще извика wakeup().

Истинското чудо се случва в sleep() и wakeup(). Те са реализирани в slp.c, източник на знаменития коментар „Не е необходимо да го разбираш“ (You are not expected to understand this). За щастие, не е нужно да разбираме кода, просто ще видим някои коментари:

/*
 * 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:
    /* Много консервативной блокировки. */

    plock(ip);

    /*
     * Если голова (чтение) догнала
     * конец (запись), сбросить оба в 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);
            }
        }

        /*
         * Если не активны ни читатель, ни
         * писатель, выйти без
         * удовлетворения чтения.
         * /

        prele(ip);
        if(ip->i_count i_mode |= IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Чтение и возврат */

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

Може да бъде по-лесно да прочетете тази функция отдолу нагоре. Ветката „чети и връщай“ обикновено се използва, когато в конвейера има данни. В този случай ние с помощта readi() четем толкова данни, колкото са налични от текущото f_offset четене, а след това обновяваме стойността на съответното отместване.

При следващо четене конвейерът ще бъде празен, ако отместването на четене е достигнало стойността i_size1 на inode-а. Ние нулираме позицията и се опитваме да събудим всякаква програма, която иска да запише в конвейера. Ние знаем, че когато конвейерът е пълен, writep() ще заспи на ip+1.А сега, когато конвейерът е празен, можем да го събудим, за да поднови своя цикъл на запис.

Ако няма какво да се чете, то readp() може да зададе флаг IREAD и да заспи на ip+2.Ние знаем, че ще бъде събуден writep(), когато запише някакви данни в конвейера.

Коментарите за readi() и writei() ще помогнат да се разбере, че вместо да предадем параметри чрез „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() блокира inode, докато не приключи работата или не получи резултат (т.е. не извика 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) беше ново основно издание (след четири години), в което се появиха много нови приложения и свойства на ядрото. Също така в него имаше значителни промени, свързани с използването на преобразувания на типове, union-и и типизирани указатели на структури. Въпреки това кодът на конвейерите практически не се е изменил. Можем да пропуснем това издание.

Xv6, просто ядро, подобно на Unix

Създаването на ядрото Xv6 е повлияно от шеста редакция на Unix, но е написано на модерен C, за да може да се стартира на x86 процесори. Кодът лесно се чете, е разбираем. Освен това, за разлика от изходния код на Unix от TUHS, можете да го компилирате, модифицирате и стартирате на нещо друго, освен PDP 11/70. Затова това ядро е широко използвано в университетите като учебен материал за операционни системи. Изходните кодове са в Github.

Кодът съдържа разбираема и обмислена реализация pipe.c, подсилена с буфер в паметта вместо inode на диска. Тук привеждам само определението на „структурния конвейер“ и функциите 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. Препоръчвам да прочетете целия му код. Сложността е на ниво изходния код на шеста редакция, но се чете много по-лесно и приятно.

Linux 0.01

Можете да намерите изходния код на Linux 0.01. Ще бъде поучително да проучите реализирането на конвейерите в него. fs/pipe.c. Тук за представянето на конвейера се използва inode, но самият конвейер е написан на модерен 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< 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;
}

Дори без да се гледа в определенията на структурите, може да се разбере как счетчикът на референции на inode се използва за проверка дали операцията по запис води до SIGPIPE. В допълнение към работа с байтове, тази функция лесно може да се свърже с описаните по-горе идеи. Дори логиката sleep_on/wake_up не изглежда толкова чужда.

Съвременните ядра Linux, FreeBSD, NetBSD, OpenBSD

Бързо прегледах някои от съвременните ядра. В нито едно от тях вече няма имплементация, използваща диск (не е изненада). В Linux има собствена имплементация. И макар че трите съвременни BSD ядра съдържат имплементации, базирани на код, написан от Джон Дайсън, през годините те значително се отклониха помежду си.

За да се четат fs/pipe.c (в Linux) или sys/kern/sys_pipe.c (в *BSD), изисква истинска отдаденост. Днес производителността и поддръжката на функции като векторни и асинхронни операции за вход/изход са важни в кода. А подробностите за управление на паметта, блокировките и конфигурацията на ядрото — всичко това се различава значително. Това не е нещо, което университетите предлагат на курсове по операционни системи.

Във всеки случай, интересно ми беше да открия няколко стари модела (например, генериране SIGPIPE и връщане EPIPE при запис в затворен тръбопровод) в тези, толкова различни, съвременни ядра. Вероятно никога няма да видя на живо компютър PDP-11, но все още има какво да се научи от кода, написан години преди моето раждане.

Статията, написана от Диви Капур през 2011 г. „The Linux Kernel Implementation of Pipes and FIFOs“ е преглед на начина, по който работят (все още) тръбопроводите в Linux. А неотдавнашен комит в Linux илюстрира модела на взаимодействие с тръбопроводи, чийто капацитет надхвърля функционалността на временните файлове; а също така показва колко далеч са се развили тръбопроводите от „много консервативната блокировка“ в шесто издание на ядро Unix.

Източник: habr.com