在较旧的Linux架构版本中，系统调用在执行期间总会产生一个中断。 通过将系统调用号码设置为％eax和参数设置为％ebx，％ecx等，然后发出特定的中断int 0x80来执行。 因此，系统调用可以说是系统中软件中断的常见原因。
但是，在x86_64的现代体系结构中，有一个特定的系统调用指令“syscall”，它绕过了使用中断0x80的需要，因此也就是中断描述符表。 虽然我相信先前为系统调用产生一个中断的方法仍然被支持，但系统调用指令似乎是在实践中完成的方式。
因此，我的问题是：说系统调用产生中断是不是正确的？ 例如，系统调用仍会增加vmstat的“中断”列输出中看到的数字吗？
是的，用于Linux x86_64的现代C代码使用syscall指令，例如参见glibc sysdeps / unix / sysv / linux / x86_64 / syscall.S。 不，这并不意味着系统调用中断由于兼容性而消失。
https://www.kernel.org/doc/Documentation/x86/entry_64.txt
x86架构有很多不同的方法可以跳入内核代码。 大多数入口点在arch / x86 / kernel / traps.c中注册，并在arch / x86 / entry / entry_64.S中实现，用于64位，arch / x86 / entry / entry_32.S，用于32位和最后一个arch /x86/entry/entry_64_compat.S，它实现了32位兼容的系统调用入口点，从而为32位进程提供了在64位内核上运行时执行系统调用的能力。
IDTvector分配在arch / x86 / include / asm / irq_vectors.h中列出。
其中一些条目是：
system_call：来自64位代码的系统调用指令。
entry_INT80_compat：来自32位或64位代码的int 0x80; compat系统调用任一方式。
entry_INT80_compat，ia32_sysenter：来自32位代码的系统调用和sysenter
而对于只读的系统调用（gettimeofday），有一个根本不进入内核模式的vDSO。
系统调用可以通过几种方式进行configuration，如ftrace或eBPF。 除了在64位模式下被淘汰之外，中断还会发生在系统调用之外的原因。