c - 实现系统调用时，如何将系统调用号暴露给用户空间？

Question

我正在摆弄系统调用。我添加了两个新的，并通过调用 syscall 验证了它们的工作。

我希望系统调用号位于 header 中，这样用户空间就不必明确知道系统调用号。

在 arch/x86/syscalls/syscall_64.tbl 我有:

317     64      krun_read_msrs                  sys_krun_read_msrs
318     64      krun_reset_msrs                 sys_krun_reset_msrs

一些 grepping 表明 kbuild 已经为新的系统调用自动生成了宏:

$ ag __NR_krun *
arch/x86/include/generated/uapi/asm/unistd_64.h
321:#define __NR_krun_read_msrs 317
322:#define __NR_krun_reset_msrs 318

文件名表明我不需要手动添加条目，但这与 Linux 内核文档所说的相反:

Some architectures (e.g. x86) have their own architecture-specific syscall tables, but several other architectures share a generic syscall table. Add your new system call to the generic list by adding an entry to the list in include/uapi/asm-generic/unistd.h:

#define __NR_xyzzy 292
__SYSCALL(__NR_xyzzy, sys_xyzzy)

好吧，我的系统调用是特定于 x86_64 的，因为它们读取和写入仅在 Intel 芯片中发现的 MSR。因此，在此之后，我开始挖掘，看看是否可以为我的 amd64 系统找到 arch-specific header。

您可能希望它位于 arch/x86_64 下，但其中根本没有包含。所以我假设 x86_64 继承自 x86。在这种情况下，arch-specific header 应该是:

arch/x86/include/uapi/asm/unistd.h

如果你打开它，它只是一个基于 arch 的小包装器:

# ifdef __i386__                                                                
#  include <asm/unistd_32.h>                                                    
# elif defined(__ILP32__)                                                       
#  include <asm/unistd_x32.h>                                                   
# else                                                                          
#  include <asm/unistd_64.h>                                                    
# endif

所以这大概是为了获取 /usr/include/x86_64-linux-gnu/asm/unistd.h 而设计的，但这还不包括我的新系统调用编号。

我希望 headers_install 目标安装新的 header (也许)，但遗憾的是它没有。

我很困惑。我是否应该手动将新系统调用添加到文件中？如果是哪个文件？如果没有，我如何将自动生成的 __NR_* 宏暴露给标准位置的用户空间？

谢谢

Answer 1

好吧，我有一个部分答案。部分因为它是特定于 Debian 的。

如果您在内核源代码中使用make deb-pkg 目标，那么将在父目录中创建.deb 包。如果您随后安装这些，那么您的 header 将安装到系统中。

在对上述内核执行此操作后:

$ grep krun /usr/include
/usr/include/asm/unistd_64.h:#define __NR_krun_read_msrs 317
/usr/include/asm/unistd_64.h:#define __NR_krun_reset_msrs 318