Linux 操作系统内核与进程的通信方式是否与IPC相同？

一个进程使用共享内存、消息传递、信令等与另一个进程通信

我了解到，如果我是对的，用同样的信号发信号也是IPC的一种方式

操作系统内核是否使用IPC的其他方式（如共享内存、消息传递）与进程通信

---

如果需要具体说明的话，我最想了解Linux内核，也很高兴了解Windows内核。

这个问题暗示了对大多数操作系统结构的根本误解

没有单独的“内核”进程进行通信。内核是在任何进程的上下文中运行的代码。内核代码由中断、陷阱或异常调用。在内核模式下，进程可以访问所有进程共享的内核内存

因此，进程和内核之间不能进行进程间通信

当内核发送信号（在Unix中）或APC（在Windoze中）时，它会在接收信号的进程的上下文中发送信号

一些信号可以在接收过程之外产生。一般顺序是：

进程p进入内核模式，并将内核内存中的信号排队以处理Q。 当进程Q成为当前进程时，内核安排Q执行信号处理程序

对于这样的信号，通信在p和Q之间；不是Q和内核

请记住，这种信号机制起源于Unix只有单一执行流的时代。这是一个穷人的异步过程调用形式（如在Windoze或VMS上）。曾经有一段时间，任何形式的对宦官的并行处理都需要创建一个单独的过程。[设计拙劣]的信号模型无法区分外部生成/异步/同步事件

Windoze（NT）遵循VMS模型，使用软件中断来通知事件进程。这个中断模型很大程度上隐藏在Windows API后面，Windows API将中断模型转换为事件模型

在中断模型中，进程可以将多个I/O请求排队到（例如）100个单独的网络连接、终端或磁盘驱动器。作为操作系统服务的一部分，调用方可以指定在请求完成时调用的过程。假设有100个终端

单个进程（应用程序）可以管理此类系统中的任意数量的设备

如果任何一个终端通过软件中断断开连接，进程都可能收到通知。中断处理程序的参数将识别特定设备，以便处理程序可以重新建立连接或清理

在经典Unix（线程之前）中，必须为每个终端创建单独的进程。进程将等待“读”或“写：操作”，等待终端响应。如果终端断开，进程将收到SIGHUP信号

---

在Windoze中，信号是C库的一部分，将软件中断转换为类似于unix信号的东西。

linux作为一种体系结构是单片的，这意味着整个内核是一个大模块，内核内部/内部通信是通过信号完成的（如unix系统）。其他内核是模块化或微内核，它们使用更灵活（更慢）的ipc。请做一些谷歌搜索！在大约30秒内，我将源代码读到signal.c，它实现了信号发送机制。投票关闭的范围太广。操作系统“通信”的方式有很多种“使用用户模式代码。可以说，用户模式代码所做的每一个API调用都是一种通信形式。@Harry：“用户模式代码所做的每一个API调用”是进程与操作系统内核通信的一种方式，而不是操作系统内核与进程通信的一种方式；如果我在和你交流，你也在和我交流。如果你指的是未经请求的通信，我不确定Windows或Linux内核是否会这样做。SIGPIPE并不是真正主动的，例如，因为它是对API调用期间出现的特定情况的直接响应；它是一个信号而不是错误代码这一事实只是一个实现细节。（所以，如果SIGPIPE算作“通信”，那么返回错误代码也是如此。）也许您可以缩小定义范围，或者提供上下文？照现在的情况，我真的不知道你在问什么。谢谢。我知道内核不是进程。这就是为什么我要问操作系统内核是否使用与IPC相同的方式与进程通信。