system call (syscall) は、user-space のプログラムが kernel にサービスを要求するために使う仕組みです — ファイルを開く、ネットワークデータを送る、メモリを確保する、プロセスを作る。これらの操作はハードウェアに触れたり他のプロセスに影響したりするため、kernel だけが実行でき、syscall は意図的に保護境界を越えます。
CPU は (少なくとも) 2 つの特権レベルのいずれかで動作します:
user mode → restricted: no direct hardware access, no privileged instructions
kernel mode → full access: hardware, all memory, privileged CPU instructions
通常の関数呼び出しは user mode のままです。syscall は制御された で kernel mode に入り、信頼された kernel コードを実行し、そして戻ります:
user code kernel
───────── ──────
read(fd, buf, n)
│ trap (syscall instruction)
└──────────────▶ enter kernel mode
validate args, do the I/O
◀────────────── return value, back to user mode
continue
この trap を自分で書くことはめったにありません — C ライブラリがそれをラップします。コード中の fopen/fread は最終的に open/read syscall を呼びます:
// glibc の read() は syscall 番号と引数をレジスタに置き、
// 続いて trap 命令 (例: x86-64 の `syscall`) を実行する。
ssize_t n = read(fd, buffer, 4096); // → kernel へ trap する
trap (ソフトウェア割り込み / 専用命令) こそが、特権レベルを安全に変えるものです — user-space のコードはただ kernel に「飛び込む」ことはできず、引数を検証する定義済みの syscall エントリポイントからしか入れません。
user/kernel の分離は OS のセキュリティと安定性の基礎です: だからこそ 1 つのプロセスがハードウェアや別プロセスのメモリに書き殴ることができません。syscall を理解するとパフォーマンスも説明できます — 各呼び出しは mode switch (数百ナノ秒) のコストがかかるため、I/O をバッチ化したり mmap/io_uring で syscall 数を減らすことが重要になり、strace (プログラムの syscall を列挙する) が強力なデバッグツールである理由もわかります。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する