🥇Unix でのパイプの実装方法

この記事では、Unix カーネルでのパイプラインの実装について説明します。最近の「」というタイトルの記事に少しがっかりしました。Unix ではパイプラインはどのように機能しますか?" 判明したノー内部構造について。私は興味を持ち、古い情報源を調べて答えを見つけました。

何それ？

パイプラインは「おそらく Unix で最も重要な発明」です。これは、小さなプログラムをまとめるという Unix の根底にある哲学の特徴であり、よく知られたコマンドラインのスローガンです。

$ echo hello | wc -c
6

この機能は、カーネルが提供するシステムコールに依存します。 pipe、ドキュメントページで説明されていますパイプ(7) и パイプ(2):

パイプラインは、プロセス間通信のための一方向チャネルを提供します。パイプラインには入力 (書き込み側) と出力 (読み取り側) があります。パイプラインの入力に書き込まれたデータは、出力で読み取ることができます。

パイプラインは呼び出しによって作成されます pipe(2)、これは XNUMX つのファイル記述子を返します。XNUMX つはパイプラインの入力を参照し、XNUMX つ目は出力を参照します。

上記のコマンドからのトレース出力は、パイプラインの作成と、それを通るあるプロセスから別のプロセスへのデータの流れを示しています。

$ 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 つの記述子に書き込み、別のプロセスが別の記述子から同じデータを読み取ります。シェルは、stdin と stdout に一致するように、dup4 を使用して記述子 XNUMX と XNUMX を「名前変更」します。

パイプラインがなければ、シェルは XNUMX つのプロセスの出力をファイルに書き込み、それを別のプロセスにパイプしてファイルからデータを読み取る必要があります。その結果、より多くのリソースとディスク領域が無駄になります。ただし、パイプラインは一時ファイルを回避するだけではありません。

プロセスが空のパイプラインから読み取ろうとすると、 read(2) データが利用可能になるまでブロックされます。プロセスが完全なパイプラインに書き込もうとすると、 write(2) 書き込みを完了するのに十分なデータがパイプラインから読み取られるまでブロックされます。

POSIX 要件と同様、これは重要なプロパティです。パイプラインへの書き込みは次のとおりです。 PIPE_BUF 通常のファイル (そのような保証はありません) では不可能な方法でプロセスがパイプラインを介して相互に通信できるように、バイト (少なくとも 512) はアトミックである必要があります。

通常のファイルを使用すると、プロセスはすべての出力をそのファイルに書き込み、それを別のプロセスに渡すことができます。または、プロセスは、外部信号メカニズム (セマフォなど) を使用して、書き込みまたは読み取りの完了を相互に通知するハード並列モードで動作することもできます。コンベヤーを使えば、こうした煩わしさから解放されます。

私たちは何を探しているのでしょうか？

コンベアの仕組みをイメージしやすいように指を使って説明します。メモリ内にバッファと何らかの状態を割り当てる必要があります。バッファーにデータを追加したり、バッファーからデータを削除したりする関数が必要になります。ファイル記述子の読み取りおよび書き込み操作中に関数を呼び出すための何らかの機能が必要になります。また、上記の特別な動作を実装するにはロックが必要です。

これで、私たちの曖昧なメンタルモデルを確認または反証するために、明るいランプの光の下でカーネルのソースコードを調査する準備が整いました。しかし、常に予期せぬ事態に備えてください。

私たちはどこを見ているのでしょうか？

私の有名な本のコピーがどこにあるかわかりません。ライオンズブック« Unix 6 ソースコードを使用していますが、おかげで Unix ヘリテージ協会オンラインで検索できますソースコード Unix の古いバージョンでも。

TUHS のアーカイブを散策するのは、まるで博物館を訪れているかのようです。私たちは私たちの共有の歴史を振り返ることができ、古いカセットやプリントアウトからこの資料すべてを少しずつ復元する長年の努力に敬意を表します。そして、私はまだ欠けている断片を痛感しています。

パイプラインの古代の歴史についての好奇心が満たされたので、比較のために現代のコアを見てみましょう。

ところで、 pipe テーブル内のシステムコール番号 42 です。 sysent[]。一致？

従来の Unix カーネル (1970 ～ 1974 年)

痕跡は見つかりませんでした pipe(2) どちらでもない PDP-7 ユニックス (1970 年 XNUMX 月)、初版 Unix (1971 年 XNUMX 月)、不完全なソースコードでも第XNUMX版（1972年XNUMX月）。

TUHSは次のように主張している第 XNUMX 版 Unix (1973 年 XNUMX 月) はパイプラインを備えた最初のバージョンでした。

Unix の第 1973 版は、アセンブラで書かれたカーネルを備えた最後のバージョンでしたが、パイプラインを備えた最初のバージョンでもありました。 XNUMX 年に第 XNUMX 版を改良する作業が進められ、カーネルが C で書き直され、Unix の第 XNUMX 版が誕生しました。

ある読者は、ダグ・マキロイが「庭のホースのようにプログラムを接続する」というアイデアを提案した文書のスキャンを見つけた。

ブライアン・カーニハンの本の中でUnix: 歴史と回想録」、コンベアの出現の歴史にもこの文書が記載されています：「...それはベル研究所の私のオフィスの壁に30年間掛けられていました。」ここマキロイのインタビューそして別の話からマキロイの作品、2014 年に書かれた:

Unix が登場したとき、コルーチンに対する私の情熱から、あるプロセスに書き込まれたデータをデバイスだけでなく別のプロセスの出口にも送信できるようにするよう、OS 作者の Ken Thompson に依頼しました。ケンはそれが可能だと考えた。しかし、ミニマリストとして、彼はすべてのシステム機能が重要な役割を果たすことを望んでいました。プロセス間の直接書き込みは、中間ファイルへの書き込みに比べて本当に大きな利点があるのでしょうか? そして、私が「パイプライン」というキャッチーな名前とプロセスの相互作用の構文の説明を使って具体的な提案をしたとき、ようやく Ken は「私がやります!」と叫びました。

そして、そうしました。ある運命的な夜、ケンはカーネルとシェルを変更し、いくつかの標準プログラムを修正して入力 (パイプラインから来る可能性がある) の受け入れ方法を標準化し、ファイル名を変更しました。翌日、パイプラインはアプリケーションで非常に広く使用されるようになりました。週末までに、秘書たちは文書をワープロからプリンターに送信するためにこれらを使用しました。少し後、Ken はパイプラインの使用をラップするための元の API と構文を、それ以来使用されているよりクリーンな規則に置き換えました。

残念ながら、第 XNUMX 版 Unix カーネルのソースコードは失われています。カーネルのソースコードは C で書かれていますが、第XNUMX版は 1973 年 XNUMX 月にリリースされましたが、正式リリースの数か月前にリリースされたものであり、パイプラインの実装は含まれていません。この伝説的な Unix 機能のソースコードが、おそらく永久に失われるのは残念です。

のドキュメントテキストがあります pipe(2) 両方のリリースから提供されているため、ドキュメントを検索することから始めることができます。第XNUMX版 (特定の単語については、「手動で」下線が引かれ、^H リテラルの後にアンダースコアが続きます!)。このプロトタイプは、pipe(2) これはアセンブラで書かれており、ファイル記述子を XNUMX つだけ返しますが、期待されるコア機能はすでに提供されています。

システムコールパイプパイプラインと呼ばれる I/O メカニズムを作成します。返されたファイル記述子は、読み取りおよび書き込み操作に使用できます。パイプラインに何かが書き込まれると、パイプラインは最大 504 バイトのデータをバッファリングし、その後書き込みプロセスが一時停止されます。パイプラインから読み取る場合、バッファリングされたデータが取得されます。

翌年までにカーネルは C で書き直され、パイプ(2) 第 XNUMX 版プロトタイプでモダンな外観を獲得しました。」pipe(fildes)»：

システムコール パイプ パイプラインと呼ばれる I/O メカニズムを作成します。返されたファイル記述子は、読み取りおよび書き込み操作で使用できます。パイプラインに何かが書き込まれると、r1 で返された記述子 (それぞれ fildes[1]) が使用され、最大 4096 バイトのデータがバッファリングされ、その後書き込みプロセスが一時停止されます。パイプラインから読み取る場合、r0 に返される記述子 (それぞれ fildes[0]) がデータを受け取ります。

パイプラインが定義されると、XNUMX つ (またはそれ以上) の対話プロセス (後続の呼び出しによって作成される) が実行されると想定されます。 フォーク) 呼び出しを使用してパイプラインからデータを渡します read и 書きます.

シェルには、パイプラインを介して接続されたプロセスの線形配列を定義するための構文があります。

エンドが XNUMX つだけ (すべての書き込みファイル記述子が閉じている) 空のパイプライン (バッファリングされたデータを含まない) からの読み取りを呼び出すと、「ファイルの終わり」が返されます。同様の状況での書き込み呼び出しは無視されます。

最古の保存されたパイプラインの実装適用する Unix の第 XNUMX 版へ (1974 年 XNUMX 月) ですが、次のリリースで登場したものとほぼ同じです。コメントを追加しただけなので、第 XNUMX 版はスキップできます。

Unix 第 1975 版 (XNUMX)

Unix ソースコードを読み始める第XNUMX版（1975年XNUMX月）。主におかげで ライオン 以前のバージョンのソースよりもはるかに簡単に見つけることができます。

長年にわたり、その本は ライオン これは、ベル研究所以外で入手可能な Unix カーネルに関する唯一の文書でした。第 XNUMX 版のライセンスでは教師がそのソースコードを使用することが許可されていましたが、第 XNUMX 版のライセンスではその可能性が除外されていたため、この本は違法にタイプ打ちされたコピーで配布されました。

現在、この本の再版版を購入できます。表紙にはコピー機に向かう学生が描かれています。そして、Warren Toomey (TUHS プロジェクトを始めた人) のおかげで、ダウンロードできるようになりました。第 XNUMX 版のソース PDF。ファイルの作成にどれだけの労力がかかったのかを説明したいと思います。

15 年以上前、私は、提供されているソースコードのコピーを入力しました。 ライオンなぜなら、他の数え切れないほどのコピーのうち、自分のコピーの品質が気に入らなかったからです。 TUHS はまだ存在しておらず、私は古い情報源にアクセスできませんでした。しかし 1988 年に、PDP9 コンピュータからバックアップされた 11 トラックの古いテープを見つけました。それが機能するかどうかを知るのは困難でしたが、無傷の /usr/src/ ツリーが存在し、ほとんどのファイルには 1979 年とマークされており、当時から見ても古いものに見えました。それは第 XNUMX 版、または PWB の派生版だと思いました。

私はその発見を基礎としてソースを第 XNUMX 版の状態に手動で編集しました。コードの一部は同じままですが、一部を少し編集する必要があり、最新のトークン += を廃止された =+ に変更しました。何かが単純に削除され、何かを完全に書き直す必要がありましたが、大したことはありませんでした。

そして今日、私たちはTUHSでオンラインで、第XNUMX版のソースコードを読むことができます。デニス・リッチーが関わったアーカイブ.

ところで、カーニハンとリッチーの時代以前の C コードの主な特徴は、一見すると次のとおりです。簡潔。サイト上の比較的狭い表示領域に合わせて大規模な編集を行わずにコードのスニペットを挿入できることは、あまりありません。

早い /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

バッファサイズは第 XNUMX 版から変更されていません。しかし、ここでは、公開文書は何もありませんが、パイプラインがかつてファイルをフォールバックストレージとして使用していたことがわかります。

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

コメントはここで何が起こっているかを明確に説明しています。しかし、コードを理解するのはそれほど簡単ではありません。その理由の XNUMX つは「構造体ユーザーu» とレジスタ R0 и R1 システムコールパラメータと戻り値が渡されます。

試してみましょう ialloc() ディスクに置く i ノード (i ノード)、そして助けを借りて falloc() - XNUMXつを保管ファイル。すべてがうまくいけば、これらのファイルをパイプラインの両端として識別するフラグを設定し、同じ i ノード (参照カウントが 2 になります) を指し、その i ノードを変更済みで使用中としてマークします。リクエストに注意してください置いた（）エラーパスで新しい inode の参照カウントをデクリメントします。

pipe() 期限までに R0 и R1 読み取りおよび書き込み用のファイル記述子番号を返します。 falloc() ファイル構造へのポインタを返しますが、経由で「返す」こともできます。 u.u_ar0[R0] そしてファイル記述子。つまり、コードは次のように保存されます。 r 読み取り用のファイル記述子と、直接書き込み用の記述子を割り当てます。 u.u_ar0[R0] XNUMX回目の通話後 falloc().

Флаг FPIPEパイプラインの作成時に設定し、関数の動作を制御します sys2.cのrdwr()、特定の 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。まず、i ノードをロックする必要があります (以下を参照) plock/prele).

次に、inode 参照数を確認します。パイプラインの両端が開いたままである限り、カウンタは 2 になるはずです。 XNUMX つのリンクを保持します (から rp->f_inode) なので、カウンターが 2 未満の場合は、読み取りプロセスがパイプラインの終端を閉じたことを意味します。言い換えれば、閉じたパイプラインに書き込もうとしているのですが、これは間違いです。最初のエラーコード EPIPE そして信号 SIGPIPE Unix の第 XNUMX 版に登場しました。

ただし、コンベアが開いていても、満杯の場合があります。この場合、別のプロセスがパイプラインから読み取り、パイプライン内に十分なスペースを解放することを期待して、ロックを解放してスリープ状態に入ります。目覚めると、最初に戻り、再びロックを解除し、新しい書き込みサイクルを開始します。

パイプラインに十分な空き領域がある場合は、次を使用してそこにデータを書き込みます。 writei()。パラメータ i_size1 inode'a (空のパイプラインでは 0 に等しくてもよい) は、すでに含まれているデータの終わりを指します。書き込むのに十分なスペースがある場合は、次からパイプラインを埋めることができます。 i_size1 до PIPESIZ。次に、ロックを解放し、パイプラインからの読み取りを待機しているプロセスを起動しようとします。最初に戻って、必要なだけのバイトを書き込むことができたかどうかを確認します。失敗した場合は、新しい記録サイクルを開始します。

通常パラメータ i_mode i ノードは権限を保存するために使用されます 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 i ノードで。位置を 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() i ノードが終了するか結果を取得するまでロックします (つまり、呼び出し 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() サイクルを再開します。

以上で第 XNUMX 版のパイプラインについての説明を終わります。シンプルなコード、広範囲にわたる影響。

第 XNUMX 版 Unix (1979 年 XNUMX 月) は、多くの新しいアプリケーションとカーネル機能を導入した新しいメジャーリリース (XNUMX 年後) でした。また、型キャスト、共用体、構造体への型付きポインターの使用に関連して、大幅な変更も加えられています。しかしパイプラインコード実質的には変わりませんでした。このエディションはスキップできます。

Xv6、単純な Unix 風のカーネル

核を作成するには Xv6 Unix の第 86 版の影響を受けていますが、x11 プロセッサで実行できるように最新の C で書かれています。コードは読みやすく、理解しやすいです。また、TUHS を使用した Unix ソースとは異なり、PDP 70/XNUMX 以外でコンパイル、変更、実行することができます。そのため、このコアはオペレーティングシステムの教材として大学で広く使用されています。情報源 Github上にあります.

コードには明確で思慮深い実装が含まれていますパイプ.c、ディスク上の i ノードではなくメモリ内のバッファーによってバックアップされます。ここでは「構造パイプライン」の定義とその機能のみを示します。 pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() 関数を含む残りの実装すべての状態を設定します。 piperead(), pipewrite() и pipeclose()。実際のシステムコール sys_pipe で実装されたラッパーです sysfile.c。彼のコードをすべて読むことをお勧めします。複雑さは第 XNUMX 版のソースコードのレベルですが、はるかに簡単で読みやすくなっています。

Linux 0.01

Linux 0.01 のソースコードを見つけることができます。彼の著書でパイプラインの実装を研究することは有益です。 fs/pipe.c。ここでは、パイプラインを表すために i ノードが使用されていますが、パイプライン自体は最新の 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;
}

構造体の定義を見なくても、書き込み操作の結果が以下であるかどうかを確認するために inode 参照カウントがどのように使用されるかを理解できます。 SIGPIPE。この関数はバイト単位の作業に加えて、上記のアイデアと比較するのが簡単です。偶数ロジック sleep_on/wake_up そんなに異星人には見えません。

Unix でのパイプラインの実装方法

何それ？

私たちは何を探しているのでしょうか？

私たちはどこを見ているのでしょうか？

従来の Unix カーネル (1970 ～ 1974 年)

Unix 第 1975 版 (XNUMX)

Xv6、単純な Unix 風のカーネル

Linux 0.01

最新の Linux カーネル、FreeBSD、NetBSD、OpenBSD

コメントを追加します返信をキャンセル

Unix でのパイプラインの実装方法

何それ？

私たちは何を探しているのでしょうか？

私たちはどこを見ているのでしょうか？

従来の Unix カーネル (1970 ～ 1974 年)

Unix 第 1975 版 (XNUMX)

Xv6、単純な Unix 風のカーネル

Linux 0.01

最新の Linux カーネル、FreeBSD、NetBSD、OpenBSD

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル