Linux内核头文件的组织

8

在阅读系统调用时，我搜索了“ syscalls.h”以在LXR中找到头文件。搜索结果使我感到困惑。在“ arch / _arch_name_ / include / asm”目录下有许多“ syscalls.h”文件。没关系，它们是体系结构特定的定义或其他需要的东西。问题是，为什么在/ include / linux和/ include / asm-generic下都有两个不同的“ syscalls.h”标头？

另外，我想弄清楚什么是/ include / linux标头，什么是/ include / asm-generic标头。它们之间如何区分？具有两个单独的头文件夹背后的逻辑是什么？它们如何相互联系？

谢谢

linux kernel linux-kernel

— 肮脏的
source

1

该软件必须是可移植的。如果编译C / C ++源代码，则无需知道是否正在运行i386 / x86_64 / arm / mips或任何其他版本。标头以软件编译的方式链接。

之所以存在所有其他头文件，是因为它们实现了许多不同的标准，其中包括来自BSD的端口等等。因此，许多都是基于历史的。每个人来自何处以及为什么会在那里有许多不同的原因，并且肯定会带来答案。

对于asm-generic的答案是：stackoverflow

— 社区
source

1

头文件asm/generic主要是作为权宜之计，是C的可移植版本，直到编写特定于体系结构的版本为止。您还会发现，在某些情况下，/usr/include/foobar.h其中包含大量的“内部实现”标头，最后回退到内核中的一部分，通常称为相同部分。示例是math.h和（更多依赖于Linux）syscall.h。

— 冯布兰德
source

0

arch/x86/entry/ 有两个特殊的syscall文件：

syscalls/syscall_32.tbl 和dito“ 64”

系统调用很特殊，因为内核必须将ABI和API结合在一起。

通常，include目录和其他头文件（独立的文件，如kernel / sched / sched.h）遵循分层逻辑。我认为make和gcc都可以发挥作用。

系统地使用这些符号来确保每个标头“单位”仅被读取一次。（“保护性包装纸”，因为交叉可能太多）。从这里include/linux/mm.h：

    #ifndef _LINUX_MM_H
    #define _LINUX_MM_H

    #include <linux/errno.h>

    #ifdef __KERNEL__

    ...  (#includes)
    ...  (ext. decl. etc., the whole mm.h)

    #endif /* __KERNEL__ */
    #endif /* _LINUX_MM_H */

tbl文件具有：

# 32-bit system call numbers and entry vectors

列表以以下内容开头：

0    i386    restart_syscall    sys_restart_syscall       __ia32_sys_restart_syscall
1    i386    exit               sys_exit                  __ia32_sys_exit
2    i386    fork               sys_fork                  __ia32_sys_fork
3    i386    read               sys_read                  __ia32_sys_read




#
# 64-bit system call numbers and entry vectors
#
# The format is:
# <number> <abi> <name> <entry point>
#
# The __x64_sys_*() stubs are created on-the-fly for sys_*() system calls
#
# The abi is "common", "64" or "x32" for this file.

稍后再进行布局...

— rastafile
source