系统调用是应用程序/用户程序请求操作系统服务来执行特权操作的唯一方式吗？

Question

尽管我知道这个主题的范围要广泛得多，但我处于 Linux 环境中

假设我正在编写一个简单的 C 程序，并且想向终端写入“Hello”。显而易见的方法是使用 C 标准库 printf，它又使用 write 系统调用（包装函数而不是系统调用本身），而 write 系统调用又调用实际的汇编系统调用指令（或 int）。不太明显的方法是在我的 C 源文件中使用一些内联汇编，或者直接创建一个包含系统调用指令的汇编文件。

我的问题

1. 似乎在一天结束时，我们以某种方式结束了系统调用（指令 syscall 或 int）。这是唯一的方法吗？

2. 在现代 PC 中，术语“应用程序”与“用户程序”的含义相同吗？

3. 我编写的 PowerPoint、Google Chrome、Visual Studio Code、Photoshop 或 C 程序都是需要系统调用来请求操作系统服务以执行写入文件等特权操作的应用程序/用户程序的示例，这样说是否正确？

Answer 1

在传统的操作系统上，是的，几乎所有操作系统服务都是通过系统调用请求的。但是，可能存在一些例外情况：

• 在发生主要页面错误时，操作系统可能会从后台存储（交换空间）中检索您的进程丢失的页面。这是您的进程无法自行执行的特权操作，但它是通过页面错误处理程序触发的。
• CPU 可能不支持某些机器指令，或者可能仅适用于特权代码。例如，这会影响MRS读取 AArch64 上的 CPU 类型和功能的指令。当用户软件执行这样的指令时，就会发生陷阱。操作系统（例如 FreeBSD）可以模拟丢失的指令或在特权上下文中执行它，然后继续执行。
• 一些操作系统支持用户空间的邮箱式接口，用户进程可以将指令包存放在环形缓冲区中，内核定期检查新工作，执行指令包，而无需用户进程显式触发系统调用。
• 有些系统支持通过共享内存进行某些设置，例如带有 vdso 的 Linux。我还依稀记得在 UNIX 中，进程可以通过将所需的信号掩码写入指定的内存块来操纵其信号掩码。然后，操作系统会在传递信号时从那里读取信号掩码。

还有其他示例，但几乎所有与操作系统的交互确实都是通过系统调用发生的。