システム コールの実際のソースを確認するには、Linux カーネル ソースが必要です。ローカル システムにインストールされているマニュアル ページには、呼び出しのドキュメントのみが含まれ、ソース自体は含まれません。
残念ながら、システム コールはカーネル ツリー全体の特定の 1 つの場所だけに保存されるわけではありません。これは、さまざまなシステム コールがシステムのさまざまな部分 (プロセス管理、ファイル システム管理など) を参照できるため、システムの特定の部分に関連するツリーの部分とは別にそれらを格納することができないためです。 /P>
あなたができる最善のことは、 SYSCALL_DEFINE[0-6] を探すことです 大きい。与えられたコードブロックをシステムコールとして定義するために（明らかに）使用されます。例:fs/ioctl.c 次のコードがあります:
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
このような定義は、ioctl syscall が宣言され、3 つの引数を取ります。 SYSCALL_DEFINE の隣の数字 引数の数を意味します。例えば getpid(void) の場合 、kernel/timer.c で宣言 、次のコードがあります:
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
少しは問題が解決することを願っています。
アプリケーションの観点から見ると、システム コールはカーネルによって実行される基本的かつ原子的な操作です。
Assembly Howto では、機械命令の観点から何が起こっているかを説明しています。
もちろん、syscall を処理するとき、カーネルは多くのことを行っています。
実際には、カーネル コード全体がすべてのシステム コールの処理に専念していると思われるかもしれません (これは完全に正しいというわけではありませんが、ほとんどです。アプリケーションの観点からは、カーネルはシステム コールを介してのみ表示されます)。 Daniel Kamil Kozar によるもう 1 つの回答は、どのカーネル関数が何らかのシステム コールの処理を開始しているかを説明しています (ただし、多くの場合、カーネルの他の多くの部分がシステム コールに間接的に参加します。たとえば、スケジューラは fork 成功した fork によって作成された子プロセスを管理するため システムコール)