所有系统调用都在内核模式下执行吗？

Question

标题说明了一切:)。

但是，让我扩展一个具体案例。

到目前为止，我已经研究了所有需要与硬件进行交互的系统调用（例如 read()、write() 等），因此在执行这些系统调用（陷阱指令）之前切换到内核模式是有意义的。

据我了解，信号纯粹是软件构造，这意味着它们不是由硬件直接生成的（与中断不同）。我将它们理解为进程（内核-内核、内核-用户或用户-用户进程）之间的消息传递机制。

Kill是一个系统调用，用于向进程发送信号。它不直接与硬件交互。那么为什么我们需要昂贵地切换到内核模式来执行该系统调用呢？我还没有发现任何“特殊”系统调用在开始执行之前不会陷入内核模式的证据。因此，问题。

Answer 1

是的，也不是。

系统调用的原始定义是由某种陷阱而不是“正常”函数调用调用的系统支持（OS）函数。因此，根据该定义，每个系统调用都需要切换到内核模式，就好像没有切换到内核模式一样，它就不是系统调用（只是正常的系统库调用）。

随着时间的推移，系统调用和库调用之间的区别已经变得模糊，因为传统上作为系统调用实现的东西（例如 getpid 或 gettimeofday）是通过其他方式实现的——通常是通过内核设置一些固定数据（也许偶尔会修改）每个过程。在Linux上，有一个“vdso”（虚拟动态共享对象）的概念，正是出于这个原因，它是为每个用户进程创建的，因此一些“系统调用”实际上是作为对此特殊内存空间的正常调用来实现的。

即使如此，哪些函数是系统调用、哪些不是系统调用的精确定义仍然存在，因为为了向后兼容，所有系统调用仍然可以通过 trap/interrupt/syscall 接口使用；只是 vdso 中可用的那些通常永远不会通过陷阱调用。这允许在 vdso 存在之前编译的非常旧的 Linux 二进制文件继续工作。