前言
Linux 内核虽然提供了多种进程间通信（IPC）机制（如信号量、共享内存、消息队列、Unix 域套接字等），但对于追求高性能或复杂功能的用户来说，现有的工具包总显得有些"捉襟见肘"。
最近，Linux 内核邮件列表（LKML）非常热闹，三项关于 IPC 增强的提案引起了广泛讨论：传统的 POSIX 消息队列 迎来升级、io_uring 试图跨界 IPC 领域，而沉寂十年的 bus1 竟然以 Rust 形式重生。
一、 POSIX 消息队列：老树开新花 (mq_timedreceive2)
POSIX 消息队列 API 虽然小众，但却是许多实时系统的核心。目前的痛点在于：一旦消息进入队列，你无法在不取出消息的情况下"偷窥"它。
1.1 核心改动：mq_timedreceive2
开发者 Mathura Kumar 提出了一个新的系统调用 mq_timedreceive2()。由于原始系统调用参数已满，新版通过结构体传参解决了架构限制：
C
struct mq_timedreceive2_args {
size_t msg_len;
unsigned int *msg_prio;
char *msg_ptr;
};1.2 新增功能
-
MQ_PEEK 标志：允许进程查看消息而不将其从队列中移除。
-
Index 索引：支持检索队列中特定位置的消息，而不仅仅是最高优先级的消息。
-
解决的问题 ：这极大地方便了监控工具（不干扰业务逻辑）和 CRIU（用户空间检查点/恢复），使备份队列状态成为可能。
二、 io_uring：从异步 I/O 到高性能 IPC
2.1 io_uring 简介
-
作用 ：
io_uring最初是为解决 Linux AIO 性能不佳而设计的异步 I/O 框架。它通过用户空间与内核空间共享的两个环形队列（Ring Buffer），实现了极低的上下文切换开销。 -
合入主线时间 ：
io_uring由 Jens Axboe 开发，并在 2019 年随 Linux 5.1 内核正式合入主线。 -
当时开发者的观点：合入之初，开发者们对其性能表现感到惊艳。虽然有人担心其安全性（增加攻击面），但其统一异步接口的潜力让大家一致认为它是 Linux 近十年来最重要的内核创新之一。
2.2 io_uring 的 IPC 提案
Daniel Hodges 的新提案试图利用 io_uring 的环形缓冲区构建一个高带宽、零拷贝的 IPC 方案。
-
解决的问题 ：现有的 D-Bus 在处理大数据量时性能较差，而
io_uringIPC 旨在通过共享环实现极致的通信效率。 -
现状：目前尚处于 POC（概念验证）阶段。维护者 Jens Axboe 表示支持，但由于代码有 LLM（大语言模型）辅助生成的痕迹，且缺乏凭证管理，仍需大量打磨。
三、 Bus1：十年磨一剑，Rust 重塑辉煌
3.1 Bus1 简介
-
作用 ：
bus1是一种内核介导的、面向对象的 IPC 机制。它不仅能传递普通数据，还能安全地传递能力（Capabilities），如文件描述符和自定义句柄。 -
解决的问题：它旨在成为一种性能比 D-Bus 更高、安全性比原始 IPC 更强的底层通信总线，为现代 Linux 桌面和系统服务提供更坚固的基石。
3.2 为什么当年（2016年）没有合入？
-
复杂性担忧 ：当时的 Linux 社区对在内核中增加如此庞大的 IPC 逻辑非常谨慎（参考
kdbus被拒的惨痛教训）。 -
维护压力：纯 C 实现的复杂生命周期管理让维护者担心内存安全和死锁问题。
-
时机不成熟 ：当时
kdbus的失败让大家对"内核总线"的概念持有偏见。
3.3 现状：以 Rust 形式回归
十年后，David Rheinsberg 带着 Rust 版本的 bus1 回归。
-
亮点 ：利用 Rust 的所有权模型完美解决了当年最令人头疼的引用计数和对象生命周期问题。
-
意义：这不仅是 IPC 的回归，更是 Rust 进入 Linux 内核核心子系统的一次重大尝试。
结语
Linux 内核的 IPC 演进呈现出两个明显趋势：一是性能至上 （如 io_uring），二是安全性与现代化（如 Rust 版 bus1）。
-
如果你追求稳定性和向后兼容，
mq_timedreceive2是福音； -
如果你追求极限性能，
io_uring的 IPC 值得期待； -
如果你关注系统架构的优雅与安全，
bus1可能是未来的答案。
对此，你怎么看？欢迎在评论区留言讨论！
