软件中断VS系统调用

Posted 2023-02-23

【中文标题】软件中断VS系统调用

【英文标题】：Software interrupts VS System calls

【发布时间】：2014-10-07 13:03:38

【问题描述】：

我有一个问题，我不知道这是否完全有道理： 如果中断向量中有一个中断函数，其中每个地址槽都是指向某个处理中断的函数的指针（一种服务，并且在内核模式下运行），那么我的问题是：

使用软件中断而不是使用系统调用（又名函数）会有所不同吗？ 举个例子：我可以在 Windows 中通过 2 种方式销毁进程：

我只是调用“ExitProcess” 我只是在汇编中使用中断“int80h”（嗯，至少在 Linux 中。在 Windows 中可以吗？）

两者都可以工作并给出相同的结果。我认为唯一的不同是中断会停止 CPU，而系统调用，因为它不是中断，所以它不会停止 CPU 做其他事情（这允许多线程并且不会因为不需要停止的事情而停止整个 CPU）。

我真正的意思是，WIN32API（或任何其他操作系统）中的所有功能都可以作为中断来实现，并且没有任何区别。然后，这将使 WIN32API 成为不必要的层。你不觉得吗？那么，软件中断和系统调用有什么区别呢？ 您只需要调用WIN32API中的函数来请求服务，而对于中断，您只需传递参数（通过堆栈或寄存器）并调用由数字标识的指定中断。 我能想到的唯一原因是 DLL（它们的实例）是按进程创建的，并且您只使用所需的功能。

这对于中断是不可能的，所有进程都将共享相同的数据，这并不总是人们想要的。

PD：这是一个超出主题但有点小问题的额外问题：我在哪里可以看到我可以在操作系统中调用的所有中断的参考/列表？我在任何地方都看不到任何文档。

【问题讨论】：

请注意，CPU 不会停止，除非您执行诸如 HLT 或 PAUSE 之类的命令。但是，它会做很多“内部”工作，例如将所有寄存器保存在堆栈中并更改位并切换到新的内存模型......正如我们所指出的那样，所有这些都是昂贵的 Jester，但 CPU 会完成所有这些工作，而且看起来它们可能会停止，但实际上并没有！

在 Windows 上，除了通过公共 API 进行系统调用是不切实际的。每次 Microsoft 发布新版本的 Windows 时，系统调用号都会更改。此外，公共 API 的工作方式通常与用于实现它们的较低级别的系统调用略有不同。即使在 Linux 上，您也最好使用库接口，因为它有更好的文档和更多功能。它甚至可能比使用旧的和缓慢的软件中断接口更快。

我很好奇优先调用而不是中断是否有性能优势。许多内核查询可以通过缓存内核数据在用户模式下解决。例如，我们可以将内核视为服务器，将中断视为同步 ajax 调用；询问服务器您登录的身份可能会很昂贵，但是如果您已经缓存了您在客户端（用户模式）上登录的身份，则无需发出中断（ajax 请求）。在用户模式和内核模式使用同一台机器的情况下，调用是否比中断便宜？

如果是这样，它可能解释了为什么微软更喜欢它的 api 作为函数（在用户模式下可调用而无需切换模式）而不是每个总是发出调用。例如，在用户模式下执行 printf 可能比让每个 printf 发出系统调用更便宜。

【参考方案1】：

系统调用基本上只是意味着调用操作系统提供的服务。实际的机制可能涉及中断、调用门或其他专用指令（syscall、sysenter、swi、trap），具体取决于架构和操作系统。

winapi 隐藏了这个机制，这是一个你不必担心的实现细节。它也可能没有记录并且可能会发生变化，而公共 API 应该是稳定的。

在 32 位 x86 linux 中，出于性能原因，使用中断 0x80 执行系统调用已经过时了十多年。在 32 位模式下，内核本身提供的代码使用内核认为最好的机制来执行系统调用。这段代码被映射到每个进程中（阅读 vdso here）。在 x86-64 linux 中，使用了专门的 syscall 指令。

此外，有些操作系统功能不需要切换到内核模式（这是一项昂贵的操作）。 API 层也可以隐藏这种差异，并自动为您提供最有效的方式。

【讨论】：

所以最终归结为两件事：1. 中断代价高昂。仅当您需要切换到内核时才需要它们。并非所有服务都需要这个。所以你最好调用OS API的函数，函数本身是否会（取决于需要）将执行模式从用户模式切换到内核模式。这将加快速度。 2. 接口稳定性 有哪些类型的中断？我的意思是，除了 int80H 之外，我对退出进程一无所知。我可以向操作系统请求哪些其他“请求”或服务？

尽管我不打算使用它，但我想更多地了解它们的用途。顺便说一句：我猜它只能在保护模式下使用，INT指令？ (***.com/questions/10583657/…)