Linux系统调用的内部 [英] Internals of a Linux system call

问题描述

当线程通过引发中断80进行系统调用时，会发生(详细)的情况? Linux对线程的堆栈和其他状态做什么工作?对处理器进行了哪些更改以使其进入内核模式?运行中断处理程序后，如何将控制恢复到调用过程?

What happens (in detail) when a thread makes a system call by raising interrupt 80? What work does Linux do to the thread's stack and other state? What changes are done to the processor to put it into kernel mode? After running the interrupt handler, how is control restored back to the calling process?

如果无法快速完成系统调用怎么办:例如从磁盘读取.中断处理程序如何放弃控制，以便处理器在加载数据时可以做其他事情，然后又如何获得控制权?

What if the system call can't be completed quickly: e.g. a read from disk. How does the interrupt handler relinquish control so that the processor can do other stuff while data is being loaded and how does it then obtain control again?

推荐答案

一个堆栈溢出的内核模式下的崩溃课程

好问题！ (面试问题?)

A crash course in kernel mode in one stack overflow answer

Good questions! (Interview questions?)

• (详细)当 线程通过引发进行系统调用 中断80?

• What happens (in detail) when a thread makes a system call by raising interrupt 80?

$ 80的int操作有点像一个函数调用. CPU捕获陷阱"并以内核模式(通常也使用不同的MMU模式)在已知地址处重新启动.内核将保存许多寄存器，尽管它不必保存程序不希望使用普通函数调用保存的寄存器.

The int $80 operation is vaguely like a function call. The CPU "takes a trap" and restarts at a known address in kernel mode, typically with a different MMU mode as well. The kernel will save many of the registers, though it doesn't have to save the registers that a program would not expect an ordinary function call to save.

• Linux对 线程的堆栈和其他状态?

• What work does Linux do to the thread's stack and other state?

通常，操作系统将保存ABI承诺在过程调用期间不会更改的寄存器.堆栈将保持不变；内核将在每个线程的内核堆栈上运行，而不是在每个线程的用户堆栈上运行.自然，某些状态会改变，否则就没有理由进行系统调用.

Typically an OS will save registers that the ABI promises not to change during procedure calls. The stack will stay the same; the kernel will run on a per-thread kernel stack rather than the per-thread user stack. Naturally some state will change, otherwise there would be no reason to do the system call.

• 对 处理器将其置于内核模式?

• What changes are done to the processor to put it into kernel mode?

这通常是完全自动的.通常，CPU具有软件中断指令，该指令有点像功能调用操作.这将导致在受控条件下切换到内核模式.通常，CPU会更改某种PSW保护位，保存旧的PSW和PC，从一个众所周知的陷阱矢量地址开始，并且可能还会切换到其他内存管理保护和映射安排.

This is usually entirely automatic. The CPU has, generically, a software-interrupt instruction that is a bit like a functional-call operation. It will cause the switch to kernel mode under controlled conditions. Typically, the CPU will change some sort of PSW protection bit, save the old PSW and PC, start at a well-known trap vector address, and may also switch to a different memory management protection and mapping arrangement.

• 运行中断处理程序后， 如何将控制权还原回 呼叫过程?

• After running the interrupt handler, how is control restored back to the calling process?

通常会有某种从中断返回"或从陷阱返回"指令，其作用有点像复杂的函数返回指令.一些RISC处理器会自动执行很少的操作，并且需要特定的代码来执行返回操作，而某些x86之类的CISC处理器具有(从未真正使用过的)指令，这些指令将执行体系结构手册伪代码页面中记录的数十种操作，以进行功能调整.

There will be some sort of "return from interrupt" or "return from trap" instruction, typically, that will act a bit like a complicated function-return instruction. Some RISC processors did very little automatically and required specific code to do the return and some CISC processors like x86 have (never-really-used) instructions that would execute dozens of operations documented in pages of architecture-manual pseudo-code for capability adjustments.

• 如果无法进行系统调用怎么办 快速完成:例如读自 磁盘.中断处理程序如何 放弃控制，以便 处理器可以做其他事情 数据正在加载以及如何执行 然后重新获得控制权?

• What if the system call can't be completed quickly: e.g. a read from disk. How does the interrupt handler relinquish control so that the processor can do other stuff while data is being loaded and how does it then obtain control again?

内核本身的线程很像线程用户程序.它只是切换堆栈(线程)并在其他人的进程上工作一段时间.

The kernel itself is threaded much like a threaded user program is. It just switches stacks (threads) and works on someone else's process for a while.

这篇关于Linux系统调用的内部的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！