kernel - 系统调用是否完整地在软件中断处理程序中执行？

Question

系统调用是否完全在软件中断处理程序的上下文中执行？

我的意思是，像 read() 这样的系统调用可能需要很长时间才能返回，这与 ISR 的执行时间应该非常短的策略相反。系统调用是否卸载到其他线程？这是如何运作的？

[对任何内核的引用都可以]

Answer 1

请阅读有关系统调用通常如何工作的引用文本:

The system call handler gains control when a user program starts a system call. The system call handler changes the protection domain from the caller protection domain, user, to the system call protection domain, kernel, and switches to a protected stack.

The system call handler then calls the function supporting the system call. The loader maintains a table of the currently defined system calls for this purpose.

The system call runs within the calling process, but with more privilege than the calling process. This is because the protection domain has changed from user to kernel.

The system call function returns to the system call handler when it has performed its operation. The system call handler then restores the state of the process and returns to the user program.

现在，关于系统调用期间的上下文切换，有两种类型的内核。
抢占式和非抢占式内核(粗略地说；因为这有时也适用于执行关键代码部分的线程/进程)。

前者在 RTOS(实时操作系统)中很常见，而后者在我们所知道的最常见的操作系统中很常见。
在抢占式内核中，调度程序可以选择退出执行系统调用的线程，以支持具有更高优先级的线程。
后者不允许这种抢占，如；如果一个线程当前正在执行系统调用，则所有其他线程都应该等到它完成其内核模式工作。

总结一下，通常在非RT系统中，如果一个线程执行了一个系统调用，它应该在被调度之前完成它的工作。
现在注意一些事情， 某些系统调用可能会阻塞 !
这是什么意思？这意味着他们将暂停直到中断发生，然后他们将返回执行，直到他们完成他们的工作。
一个例子是 read()，它会阻塞直到用户请求的数据准备好；同时可以安排其他线程运行，但是一旦中断到达该 read() 它将再次开始运行并且没有人可以调度它(再次，仅在非抢占环境中)直到它返回给用户着陆结果。