系统调用探针管理器

系统调用探针管理器支持在定义明确并记录在案的基本AIX®系统调用的入口和出口处进行探针。 这些是在 libc.a(或 C 库)入口点和内核入口点处具有相同接口的系统调用。 系统调用是传递 (C 库只是从内核导入符号,然后不带库中的任何代码将其导出)或具有库中的接口小代码。

syscall 探针管理器接受以下某种格式的 4 重调查规范:

  • syscall:*:<system_call_name>:entry
  • syscall:*:<system_call_name>:exit
其中 system_call_name 字段将替换为实际的系统调用名称。 这些表示调查位于系统调用的入口和出口处。 将 * 指定给第二个字段表示将为所有进程触发调查。
注: 启用系统调用探测器需要不同的特权。 调查系统中的所有进程所需的特权比调查您自己的进程所需的特权要高。

另外,syscall 探针管理器还接受以下某种格式的 4 重调查规范:

  • syscall:<process_ID>:<system_call_name>:entry
  • syscall:<process_ID>:<system_call_name>:exit

其中,可在调查规范的第二个字段中指定进程标识,从而支持对特定的进程进行调查。

syscall 探针管理器接受的系统调用名称是 libc.a 接口的名称,而不是内核的内部系统调用名称。 例如,read 子例程由 libc.a 导出,而实际的系统调用名称或内核入口点是 kread。 syscall 探针管理器将在内部将 libc 接口转换为其内核入口点并使入口的调查进入 kread 内核例程。 因此,如果多个 C 库接口调用 kread 例程,那么此探针点也会针对这些接口触发。 通常,这并不会造成问题,因为对于 syscall 探针管理器支持的大多数系统调用,在 libc 接口和内核例程之间存在 1 对 1 的映射。

对于每个 syscall 调查,在库代码中都有一个 uft 探针管理器提供的等同探针点。 uft 探针管理器支持所有库接口(除非是传递接口且在库中没有调用代码或其引用),包括 syscall 探针管理器不支持的接口。 然而,syscall 探针管理器有两个优势:

  • syscall 探针管理器可以通过在第二个字段中指定星号来调查系统中的每个进程。
  • syscall 探针管理器比 uft 探针管理器更有效,因为它不需要在用户方式和内核方式之间进行切换就可运行调查操作。

有关 syscall 探测器管理器支持的系统调用的完整列表的更多信息,请参阅 ProbeVue