syscall プロバイダは、システムコールごとにプローブを 1 組ずつ提供します。 うち 1 つは、システムコールに入る前に起動する entry プローブです。もう 1 つは、システムコールが完了したあと、ユーザーレベルの制御に戻る前に起動する return プローブです。どの syscall プローブでも、関数名は計測されるシステムコールの名前です。モジュール名は未定義です。
syscall プロバイダが提供するシステムコールの名前は、/etc/name_to_sysnum ファイルで確認できます。多くの場合、syscall が提供するシステムコールの名前は、マニュアルページのセクション 2 の名前と対応しています。しかし、syscall プロバイダが提供するプローブの中には、文書化されたシステムコールに直接対応していないものもあります。以下では、この矛盾の主な原因について説明します。
syscall プロバイダが提供するシステムコールの名前が、以前の実装内容を反映している場合があります。たとえば、以前の UNIXTM を反映して、/etc/name_to_sysnum ファイル内では exit(2) の名前が rexit になっています。同様に、time(2) の名前は gtime、execle(2) と execve(2) の名前はどちらも exece になっています。
セクション 2 のシステムコールの一部は、文書化されていないシステムコールの下位操作として実装されています。たとえば、System V セマフォ関連のシステムコール (semctl(2)、semget(2)、semids(2)、semop(2)、および semtimedop(2)) は、semsys という単一のシステムコールの下位操作として実装されています。semsys システムコールは、最初の引数として、要求されたシステムコールを示す実装固有の「サブコード」(SEMCTL、SEMGET、SEMIDS、SEMOP、または SEMTIMEDOP) を取ります。単一のシステムコールを使用して複数のシステムコールを実装しているため、複数の System V セマフォに対して syscall プローブは syscall::semsys:entry および syscall::semsys:return の 1 組だけ存在します。
4G バイトを超える大規模ファイルをサポートする 32 ビットプログラムは、64 ビットファイルのオフセットを処理できなければなりません。大規模ファイルの場合、大規模オフセットを使用するため、大規模ファイルを操作するときは、複数のシステムインタフェースを並行して利用します (lf64(5) のマニュアルページを参照)。これらのインタフェースについては、lf64 に記載されています。ただし、インタフェースごとに個別のマニュアルページは用意されていません。これらの大規模ファイルシステムコールインタフェースは、表 21–1 のように、独自の syscall プローブとして記載されています。
表 21–1 sycall 大規模ファイルプローブ
大規模ファイル syscall プローブ |
システムコール |
---|---|
creat64 | |
fstat64 | |
fstatvfs64 | |
getdents64 | |
getrlimit64 | |
lstat64 | |
mmap64 | |
open64 | |
pread64 | |
pwrite64 | |
setrlimit64 | |
stat64 | |
statvfs64 |
一部のシステムコールは、ユーザーとカーネル間の境界にまたがる Solaris サブシステムの非公開実装です。このため、マニュアルページのセクション2 に、これらのシステムコールはありませんこのようなシステムコールの例として、POSIX.4 メッセージキューの実装の一部として使用される signotify システムコールや、fuser(1M) を実装するために使用される utssys システムコールなどがあります。