差分
/* カーネル空間とユーザ空間 */
+--+
ハードウェア資源
=== システムコール ===
システムコールはユーザ空間からカーネル空間で処理を行うための切替えポイントです。今風にいうならばカーネルとのAPIとして用意された関数群です。UNIXではシステムコールと呼びます。
カーネル空間に処理が入ってしまうと基本的にユーザはタッチすることができません。もし制限なしにユーザ側からカーネル空間を操作できるということであれば、システムのどの部分にもアクセスできるということと同じ意味なので、極めて重大なシステム障害やセキュリティ侵害をいとも簡単におこすことが出来るようになります。
システムコールはたくさんあります。どのようなシステムコールがあるのかを調べるにはオンラインマニュアルをチェックするのがいいでしょう。システムコールはセクション2に含まれています。オンラインマニュアルのファイル数を数えると約300個ありました。
;調べてみよう: 今使っているLinuxにはおおよそいくつのシステムコールが用意されているのが調べてみよう。次に、既に使われなくなりなくなったシステムコールと、互換性のために残してあるが使用するのに推奨されていないシステムコールを1つ以上みつけてみよう。欠番となっているシステムコールを探すには/usr/include/asm/unistd.hがヒントになります。
ユーザ側から見た目はシステムコールもライブラリ関数も一見違いがありません。ただし実際の動作ではシステムコールの呼出は、ユーザ空間からカーネル空間へモードが移行するコストがかかるので、たとえまったく同じ内容の処理をするにしても、同じユーザ空間で動作しているライブラリを呼び出すよりもコストがかかります。
;補足: この逆のこともいえます。システムから上がってくる処理をユーザ空間まで処理を移行せず、直接カーネルの中で処理をすれば、それだけ移行するコストを削減でき処理が速くなります。例としてはLinux 2.4系に入っていたkhttpd(カーネル版サーバ：ただし2.6系では削除されています) があります。
もう少し、システムコールとライブラリ関数の関係を見てみます。システムコールであるwrite (2)と ライブラリ関数であるfwrite(3) は、一見似たようなものに見えます。
write (2)
#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count);
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文化圏では、基本的なレベルに分割されるべきソフトウェアが肥大していくのはよくない傾向であると考えられています。
匿名利用者
