一、引言
在 Zephyr RTOS 面向多核 MCU、异构 SoC 以及安全域隔离（如 Secure / Non-secure）的应用场景中，核间通信（IPC）是一个绕不开的基础能力。为了在不同硬件平台之间提供统一的软件抽象，Zephyr 提供了Mailbox（mbox）子系统。
与 Linux Mailbox 子系统类似，Zephyr 的 mbox 也并不是一个完整的消息协议栈，而是：
对底层 Mailbox / Doorbell /IPC硬件的一层轻量级、实时友好的抽象接口。
本文将以源码结构和关键数据结构为主线，系统性讲解 Zephyr mbox 子系统的设计思想、代码组织方式以及典型的数据收发流程，帮助读者在阅读 Zephyr 内核源码、分析时快速建立整体认知框架。
二、Zephyr mbox 子系统的设计定位
在整体软件架构中，Zephyr mbox 的定位可以概括为三点：
偏实时、偏硬件直连设计上优先考虑中断延迟、上下文切换开销和可预测性。
不承载大数据传输mbox 通常只用于短消息、事件通知或共享内存的“kick”信号。
作为上层协议的基础设施常被 OpenAMP、IPC service、厂商自定义通信框架使用。
这决定了 Zephyr mbox 在接口与实现上都保持了较小的复杂度。
三、源码组织结构总览
Zephyr mbox 相关代码主要分布在以下位置：
include/zephyr/drivers/mbox.hmbox 对外接口定义与核心数据结构drivers/mbox/各类硬件 Mailbox 控制器驱动实现include/zephyr/device.h/drivers/*与 Zephyr 设备模型的集成
整体调用关系可以抽象为：
mbox API
↓
mbox driver API（struct mbox_driver_api）
↓
具体 Mailbox 硬件驱动
与 Linux 不同，Zephyr 并没有一个复杂的“框架层”，而是更直接地采用driver API 分发模型。
四、核心数据结构详解
struct mbox_msg —— 消息抽象
struct mbox_msg是 Zephyr mbox 子系统中最核心的消息描述结构，用于表示一次 Mailbox 传输。
从设计角度看，它并不关心消息的“语义”，而只描述：
消息数据
消息长度
典型字段包括：
data / size指向消息数据及其长度，通常很短。
这一设计使得 mbox_msg 可以同时适配：
单向通知
请求 / 响应式通信
共享内存协同模型
struct mbox_callback —— 回调机制
Zephyr 强调事件驱动模型，因此 mbox 提供了回调结构：
接收完成回调
发送完成回调
回调函数通常运行在中断上下文或系统工作队列上下文，这对驱动实现提出了明确约束：
回调中不应执行阻塞操作。
struct mbox_driver_api —— 驱动接口核心
struct mbox_driver_api是 Zephyr mbox 子系统中最关键的抽象接口，其作用类似于 Linux 中的mailbox_controller_ops。
它定义了一组函数指针，用于描述硬件 Mailbox 控制器能够提供的能力。
常见接口包括：
send向指定 Mailbox 通道发送一条消息。
register_callback / unregister_callback注册或注销接收回调。
set_enabled启用或禁用某个 Mailbox 通道（通常映射到中断开关）。
从架构上看：
mbox_driver_api 是 Zephyr mbox 子系统中唯一的“策略与硬件分界线”。
五、Zephyr 设备模型与 mbox 的结合
DEVICE_DT_DEFINE 与 mbox
Zephyr 中的 mbox 控制器通常作为一个普通设备注册：
使用
DEVICE_DT_DEFINE从 Device Tree 中获取通道数量、中断号等信息
mbox 并不单独维护全局资源池，而是完全依赖 Zephyr 的设备模型进行生命周期管理。
多实例与多通道支持
在 Zephyr 中：
一个 mbox 设备可以支持多个 channel
channel 通常通过整数 ID 区分
channel 的分配策略完全由具体驱动决定，而非框架统一管理，这与 Linux 的 channel 仲裁模型形成鲜明对比。
六、发送路径源码级分析框架
典型的发送流程如下：
应用 / 上层协议
↓
mbox_send(dev, channel, msg)
↓
mbox_driver_api.send
↓
硬件 Mailbox 寄存器写入
在这一过程中：
mbox 核心层几乎不做逻辑处理
不维护发送队列
不做复杂状态机
这种设计非常符合 Zephyr 对实时性与确定性的要求。
七、接收路径与中断处理模型
接收路径通常由中断触发：
Mailbox 硬件产生中断
驱动中断处理函数读取寄存器
构造
mbox_msg调用已注册的回调函数
关键设计点在于：
驱动必须明确区分ISR上下文与线程上下文
回调是否延迟执行由驱动自行决定
这给了驱动作者极大的自由度，但也要求对并发模型非常清楚。
八、Zephyr mbox 与 OpenAMP / IPC Service 的关系
在多核 SoC 场景中，Zephyr mbox 常作为：
OpenAMP 的底层通知机制
IPC Service 的事件触发通道
在这些场景下：
mbox 负责“通知”
实际数据放在共享内存中
这与 Linux rpmsg + mailbox 的分层思想高度一致。
九、与 Linux Mailbox 设计的对比
从架构风格上看，两者差异明显：
| 维度 | Linux | Zephyr |
| 框架复杂度 | 高 | 低 |
| channel 管理 | 框架统一 | 驱动自定义 |
| 发送队列 | 有 | 无 |
| 实时性优先级 | 中 | 高 |
可以认为：
Linux Mailbox 偏“通用操作系统”，Zephyr mbox 偏“实时控制系统”。
十、总结
从源码视角来看，Zephyr 的 mbox 子系统是一套极度简洁但边界清晰的 IPC 抽象：
用
mbox_msg描述一次通信用
mbox_driver_api隔离硬件差异把策略、调度和队列尽量留给上层
理解这一点后，再去阅读具体平台（如 NXP、TI、ARM、RISC-V SoC）的 mbox 驱动代码，会发现其实现逻辑非常直接，几乎是一一映射硬件能力。
对于希望深入研究Zephyr 多核通信、OpenAMP、IPCService的开发者而言，mbox 子系统是一个非常理想的切入点。
