我从“Modern Operating Systems , Tanenbaum”中读到这一段
大多数计算机有两种操作模式：内核 模式和用户模式。操作系统是最基本的软件，以内核模式（也称为监督模式）运行。在这种模式下，它可以完全访问所有硬件，并且可以执行机器能够执行的任何指令。软件的其余部分在用户模式下运行，其中只有一部分机器指令可用。
根据可用的机器指令，我无法了解他们如何描述这两种模式的差异，在用户端，任何软件都有能力在硬件级别进行任何更改，就像我们有可能影响功能的软件一样CPU 的，可以玩注册表细节，所以我们怎么能说在用户模式下，我们只有机器指令的子集？
【问题讨论】：
标签： operating-system
仅在内核模式下可用的指令往往很少。这些说明仅用于管理系统。
例如，大多数处理器都有一条 HALT 指令，用于停止用于系统关闭的 CPU。显然，您不希望任何用户能够执行 HALT 并为每个人停止计算机。然后这些指令只能在内核模式下访问。
处理器使用处理程序表来处理中断和异常。操作系统创建这样一个表，列出这些事件的处理程序。然后它加载给出表的位置（和大小）的寄存器。加载此寄存器的指令仅适用于内核模式。否则，任何应用程序都可能对系统造成严重破坏。
如果在用户模式下执行，这些性质的指令将触发异常。
这样的说明往往很少。
【讨论】：
嗯，在user-mode 中，肯定有可用的指令子集。这就是我们拥有System Calls 的原因。
示例：
用户想要在 C 中创建一个新进程。如果不输入 kernel-mode，他将无法做到这一点，因为某些指令集仅对 kernel-mode 可用，因此他使用 system call fork，执行创建新进程的说明（user-mode 中不可用）。所以System call 是一种从OS 的kernel 请求服务来为用户做一些他/她无法编写代码的机制。
以下链接的摘录以最好的方式总结了它：
一个程序通常被限制在它自己的地址空间内，因此它 无法访问或修改其他正在运行的程序或操作系统 本身，并且通常被阻止直接操作硬件 设备（例如帧缓冲区或网络设备）。
但是，许多正常的应用程序显然需要访问这些 组件，因此操作系统可以使用系统调用 为此类操作提供定义明确、安全的实现。这 操作系统以最高权限执行，并且 允许应用程序通过系统调用请求服务，系统调用是 通常通过中断启动。中断会自动将 CPU 进入某个提升的特权级别，然后将控制权交给 内核，它决定是否应该授予调用程序 请求的服务。如果服务被授予，内核执行 调用程序没有的一组特定指令 直接控制，将特权级别返回到调用者的级别 程序，然后将控制权返回给调用程序。
【讨论】：