我正在内联系统调用。是的，我知道这是有问题的，但我有充分的理由。我已经找到了相当多的bug，我只是想问为什么 __ NR_open 在这个arm64 Arch Linux系统上消失了？
5.0.1-1-ARCH＃1 SMP Sun Mar 10 15:08:34 MDT 2019 aarch64 GNU / Linux
同样，我的代码内联了系统调用。这种内联方法可以在另一个 X86_64 系统上使用，而实际上内联 mmap（）可以在该系统上使用。但是，在此arm64 Arch Linux上内嵌 open（）失败，并显示 EFAULT 。
首先要跟踪我的错误，在此构建环境中甚至没有定义 __ NR_open 。其次，常规的 open（）调用 open64（），该命令执行x8设置为＃56的 svc 指令， __ NR_openat 。第三， __ NR_open 通常定义为5，并且该数字已重新指定为 __ NR_setxattr 。这说明了 EFAULT 。
基本上， open（）在此系统上的用户库中转换为 openat（），并且 __ NR_open 系统调用已完全消失，由新的系统调用接管。我不明白的是 __ NR_open 是在canonical source中为arm64定义的，但不是在此Arch Linux arm64系统上定义的。
我的错误修复很简单：改为内联 openat（）。但是我的问题是为什么要删除此文件，为什么不认为这与Linux POV无关？我在想Linus说我们不要破坏用户空间！，而我不是在POSIX POV上考虑这个问题。实际上， Linux编程接口至少没有明确地没有涵盖此删除操作。
答案 0 :(得分：3)
您正在查看的文件arch/arm64/include/asm/unistd32.h是arm32兼容模式的系统调用定义。
本机aarch64的系统调用定义来自通用系统调用表include/uapi/asm-generic/unistd.h，您可以看到它没有定义__NR_open。系统调用未删除-它在aarch64上从未存在。
未在通用表中定义__NR_open的原因是openat(2)系统调用是稍后引入的，并且是_NR_open功能的严格超集，因此没有意义在 new 体系结构端口中（引入openat(2)之后创建）提供该系统调用-这是多余的。 POSIX open()函数由用户空间C库提供，并调用openat(2)系统调用。
在openat(2)之前存在的旧体系结构端口（例如x86和arm32）必须继续包含open(2)，因为对于那些调用{{1}的体系结构，确实存在旧程序/库二进制文件}系统调用。这种担心不适用于新的体系结构端口-“中断的用户空间”保证是，如果昨天运行，它将在今天运行，但是并没有说，如果它在现有体系结构上运行，则可以重新编译并在某些新版本上运行。建筑。
答案 1 :(得分：0)
为什么在某些Linux系统上不支持open（）系统调用？
现在，技术答案很简单：
因为有人这样写。
但是我的问题是为什么要删除此文件，为什么不认为这是从Linux POV断开的？
这不是技术问题，而是哲学问题。
是什么阻止任何人派生Linux内核并对其进行任意更改？
自从我阅读GNU GPL已经有一段时间了，但是我没有提到这种限制。
也许打破系统调用ABI兼容性 被认为是从Linux POV断开的，但是据我所知，这种观点不具有对任何第三方的有效权利（法律或自然权利）。
问问谁运送了您正在运行的AArch64 Linux分支，也许强大的功能就会启发您选择它们的原因。