差分
/* システムコール */
;補足: khttpdは本気でWebの能力をカーネルに入れるためではなく、質の悪いベンチマークテストへの皮肉として入れているので、Web処理を本気でカーネルで処理しようとしたなどと誤解しないようにしてください。
もう少し、システムコールとライブラリ関数の関係を見てみます。システムコールであるwrite (2)と ライブラリ関数であるfwrite(3) は、一見似たようなものに見えます。
fwrite(3)の方は、ユーザ空間で動作していて、さらに入出力を効率的にするためのバッファを用いています。バッファはファイルポインタFILE *stream が保持しています。/usr/include/libio.hの構造体である struct _IO_FILE を見てみるとわかります。ですからfwrite(3)を呼び出したからといって、その先のファイル（あるいは書き出す実体）へ書き込んでいるとは限りません。
write(2)はオープンしているディスクリプタfdに書き込みます。ですからファイル（書き出す実体）へ、データを書き込みます。writeはオープンしているファイルディスクリプタfdに書き込みます。これはファイル（書き出す実体）へ、データを書き込みます。write(2)を使うと入出力効率が落ちるならば、fwrite(3)のような機能をシステムコールレベルでサポートすればいいではないかという考え方をしたくなるはずです。
しかし、そのようなことをすればするほど、当然ながらカーネルのコードサイズが増大していきます。カーネルが肥大すればするほど、その分、移植性が損なわれていきますし、また、一部を書き換えようとすると、カーネルやカーネルモジュールを入れ換えることになってしまい非効率的です。カーネルは最低限のことをすばやく動かすことをするすべきであって、それ以外、別にカーネルでなくてもできる範囲は、ユーザ空間ですべきであるという切り分けの方が安定性やメンテナンス性が向上するというアドバンテージがあります。逆に、これが将来的に発展性も乏しく、新しい機能も入らず固定化しているような、停滞しているようなオペレーティングシステムであれば、どんどんカーネルに組み込んでいく可能性もあるでしょう。
;補足: 少なくとも、カーネルに関しては、何でもかんでも組み入れて肥大化していく例は見当たりませんが、一般的なアプリケーションに関してはよく見られる傾向です。もちろんカーネルでも一般的なアプリケーションに関してもよく見られる傾向です。もちろん"Small is Beautiful"という言葉が好きなUNIX文化圏では、基本的なレベルに分割されるべきソフトウェアが肥大していくのはよくない傾向であると考えられています。という言葉が好きなUNIX文化圏では、基本的なレベルに分割されるべきソフトウェアが肥大していくのは好ましくない傾向であると考えられています。しかし、現実には肥大する方向に向かっているのも事実ではあります。
=== カーネルの構造 ===
匿名利用者
