システムコールとカーネル

なぜ世界を2つに分けるのか：保護

もし全アプリがメモリやディスク、CPU を直接好き勝手に触れたら、たった1つのバグや悪意あるプログラムが、他のアプリや OS そのものを巻き込んで壊せてしまいます。そこで OS は CPU の機能を使い、実行環境を2つに分離します。

• ユーザー空間（user space）：アプリが動く世界。権限が制限され、ハードへの直接アクセスや他プロセスのメモリ参照はできない。
• カーネル空間（kernel space）：OS の中核（カーネル）が動く世界。すべての特権を持ち、ハードやメモリ、CPU を直接制御できる。

この境界は、CPU が持つ 特権モード（保護リング） で物理的に守られています。x86 では特権レベルを「リング0〜3」で表し、一般に カーネルがリング0、アプリがリング3 で動きます。

• カーネルモード（特権モード / リング0）：特権命令を実行でき、全メモリ・全ハードにアクセス可能。
• ユーザーモード（非特権モード / リング3）：実行できる命令もアクセスできるメモリも制限される。

ユーザーモードのアプリが特権命令を直接実行しようとすると、CPU が 例外（トラップ） を発生させ、カーネルが介入します。だからアプリは「自分でやる」のではなく「頼む」しかないのです。

ユーザー空間とカーネル空間

つまりアプリは「狭い安全な部屋」で動き、ハードや他プロセスという「外」に触れたいときだけ、システムコールというドアを叩いてカーネルに頼む、という構図です。

システムコールが呼ばれる仕組み

「アプリ → カーネル」は単なる関数呼び出しではありません。特権の壁を越えるため、専用の手順を踏みます。おおまかな流れはこうです。

1. アプリが「何をしてほしいか」を決める（例：このファイルを読む）。
2. システムコール番号と引数を、CPU の決まった場所（レジスタなど）にセットする。
3. 特別な命令（x86-64 なら syscall、古くは int 0x80 などの ソフトウェア割り込み / トラップ）を実行する。
4. CPU が ユーザーモード → カーネルモードへ切り替え、実行はカーネル内の入口（ディスパッチャ）に移る。
5. カーネルが番号を見て対応する処理を実行し、結果（戻り値・エラー） を返す。
6. カーネルモード → ユーザーモードへ戻り、アプリは続きを実行する。

[ユーザー空間]  アプリ
     │  ①番号と引数をセット
     │  ②syscall 命令（トラップ）
     ▼ ───── 特権の壁（モード切替）─────
[カーネル空間]  ③番号で処理を選ぶ → ④実際の仕事
     │  ⑤結果を返す
     ▼ ───── 壁を戻る（モード切替）─────
[ユーザー空間]  アプリが続きを実行

ポイントは、アプリがカーネルの中の関数を直接呼んでいるわけではないこと。アプリは「番号で依頼を投げる」だけで、実際に走るコードや権限の切り替えは CPU とカーネルが担います。これがただの関数呼び出しと違い、無視できないコスト（モード切替のオーバーヘッド）を伴う理由です。

代表的なシステムコール

数百ありますが、まず押さえるべきはファイル系とプロセス系です。

ファイル I/O：open → read/write → close

UNIX 系では「すべてはファイル」という思想があり、通常ファイルだけでなく、端末・パイプ・ソケット（ネットワーク通信）まで、同じ read/write で扱えます。open が返す ファイルディスクリプタ（fd＝小さな整数） を、以降の操作で「どの対象か」を指す取っ手として使います。標準入力=0、標準出力=1、標準エラー=2 は、起動時から開いている fd です。

// ファイルを開いて中身を読む最小例（エラー処理は省略）
int fd = open("data.txt", O_RDONLY);   // ← システムコール
char buf[256];
ssize_t n = read(fd, buf, sizeof buf); // ← システムコール
close(fd);                             // ← システムコール

プロセス生成：fork と exec

UNIX で新しいプログラムを起動する定番は、fork で自分を複製し、その子で exec して別プログラムに化けるという二段構えです。シェルがコマンドを実行する仕組みもこれです。

親プロセス ──fork()──┬─ 親：そのまま続行（必要なら wait で子を待つ）
                     └─ 子：exec("/bin/ls") で ls に置き換わって実行

ライブラリ関数との関係

「じゃあ普段書く printf や fopen はシステムコール？」——いいえ、それらは 標準ライブラリ（C なら libc）の関数で、システムコールそのものではありません。多くのライブラリ関数が、内部でシステムコールを呼んでいるという関係です。

あなたのコード
   │  printf("hello")          ← ライブラリ関数（libc）
   ▼
標準ライブラリ（バッファリング・書式整形などを担当）
   │  write(1, ...)            ← システムコール（依頼）
   ▼
カーネル → 実際に端末やファイルへ出力

ライブラリ関数を挟む利点は2つ。1つは 移植性——OS ごとに違うシステムコールの差を吸収し、printf のような共通インターフェースを提供します。もう1つは 効率——前述のバッファリングでシステムコール回数を減らし、重いモード切替を節約します。malloc も同様に、必要なときだけ brk/mmap をまとめて呼び、細かな確保はライブラリ内で捌いています。

まとめ