差分

移動先: 案内検索

カーネルの構造と機能

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