嵌入式 Linux 进程间通信：D-Bus、共享内存与 Unix Socket

嵌入式 Linux 系统中，多个进程协同完成任务是常态：传感器采集进程把数据交给显示进程，控制逻辑通过守护进程下发指令，日志服务从各模块收集状态。进程间通信（IPC）的选择直接决定了系统延迟、可靠性和可维护性。本文聚焦三种在嵌入式场景中高频使用的 IPC 机制——D-Bus、共享内存和 Unix Socket，从适用场景、性能特征和工程取舍三个维度给出判断框架。

实践中没有万能方案。D-Bus 适合结构化的服务发现与消息路由，共享内存适合高吞吐低延迟的原始数据交换，Unix Socket 适合可靠的流式或数据报通信。选型时需要同时考虑数据量级、实时性要求、安全隔离粒度和团队维护成本。

一、问题背景

嵌入式 Linux 与桌面 Linux 的 IPC 需求存在本质差异。资源受限环境下，内存和 CPU 余量有限，不能像桌面系统那样随意引入重型中间件；同时，实时性要求使得某些场景下微秒级的延迟差异就足以影响系统行为。此外，嵌入式系统的 IPC 还必须考虑进程崩溃后的恢复、权限隔离以及跨平台移植性。

本文讨论范围限定在用户空间进程间通信，不涉及内核驱动层面的 ioctl、netlink 或共享内存的内核态用法。讨论的三种机制分别代表三种典型模式：D-Bus 是消息总线模式，共享内存是零拷贝模式，Unix Socket 是传统 socket 模式的本地化变体。

二、核心思路

D-Bus 的本质是服务注册与消息路由。它提供名称服务、接口定义和类型安全的消息序列化，适合需要服务发现和方法调用的场景，如系统服务管理、配置下发。代价是序列化开销和守护进程（dbus-daemon）的额外资源占用。
共享内存是延迟最低的 IPC 方式。通过 shmget/mmap 将同一块物理内存映射到多个进程地址空间，数据传递零拷贝。但它不提供同步机制，需要配合信号量、futex 或无锁队列使用，工程复杂度较高。
Unix Socket 兼顾灵活性和可靠性。支持 SOCK_STREAM（有序可靠）和 SOCK_DGRAM（无序无连接），既可传递结构化消息，也可直接转发原始字节流。它是嵌入式系统中最通用的 IPC 骨干。
选型的关键判据是数据特征和耦合度。高频小数据包、低延迟要求→共享内存；结构化服务调用、需要接口版本管理→D-Bus；中等频率、需要可靠传输和简单实现→Unix Socket。

三、落地步骤

1. 共享内存方案示例

#include <sys/shm.h>
#include <sys/sem.h>
#include <stdio.h>
#include <string.h>

#define SHM_KEY 0x1234
#define SEM_KEY 0x5678
#define SHM_SIZE 4096

struct sensor_data {
    uint32_t timestamp;
    float    temperature;
    float    humidity;
};

int main(void) {
    int shmid = shmget(SHM_KEY, SHM_SIZE, IPC_CREAT | 0666);
    if (shmid < 0) { perror("shmget"); return 1; }

    struct sensor_data *shared = shmat(shmid, NULL, 0);
    if (shared == (void *)-1) { perror("shmat"); return 1; }

    int semid = semget(SEM_KEY, 1, IPC_CREAT | 0666);
    semctl(semid, 0, SETVAL, 1);

    /* 生产者写入数据 */
    struct sembuf op = {0, -1, 0};
    semop(semid, &op, 1);

    shared->timestamp = 1721686981;
    shared->temperature = 25.3f;
    shared->humidity = 60.1f;

    op.sem_op = 1;
    semop(semid, &op, 1);

    shmdt(shared);
    return 0;
}

2. Unix Socket 方案示例

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

#define SOCK_PATH "/tmp/embedded_ipc.sock"

int main(void) {
    int fd = socket(AF_UNIX, SOCK_STREAM, 0);
    if (fd < 0) { perror("socket"); return 1; }

    struct sockaddr_un addr;
    memset(&addr, 0, sizeof(addr));
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1);
    unlink(SOCK_PATH);

    if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind"); return 1;
    }
    listen(fd, 5);

    int client = accept(fd, NULL, NULL);
    if (client < 0) { perror("accept"); return 1; }

    const char *msg = "temp=25.3,humidity=60.1";
    write(client, msg, strlen(msg));

    close(client);
    close(fd);
    unlink(SOCK_PATH);
    return 0;
}

3. D-Bus 方案要点

使用 D-Bus 需要定义 XML 接口描述文件，通过 dbus-binding-tool 或手动编写适配代码。嵌入式场景推荐使用轻量级的 dbus-broker 替代传统的 dbus-daemon，可显著降低内存占用。关键配置步骤：

编写接口 XML，定义方法、信号和属性。
实现服务端，调用 dbus_connection_register_object_path 注册处理函数。
客户端通过 dbus_connection_call_with_reply 发起方法调用。
在 /etc/dbus-1/system.d/ 中配置策略文件控制访问权限。

四、常见坑

共享内存的竞态条件。不加同步机制直接读写共享内存，生产者和消费者会读到中间态数据。务必配合信号量或使用原子操作的无锁队列。
Unix Socket 的路径残留。进程异常退出后 socket 文件不会自动删除，重启时 bind 会失败。应在启动时调用 unlink 清理，或使用抽象命名空间（以 \0 开头的路径）避免文件系统残留。
D-Bus 的线程模型陷阱。dbus_connection 默认不是线程安全的，多线程访问必须手动加锁或为每个线程创建独立连接。嵌入式场景中单线程事件循环更可靠。
共享内存的权限管理。shmget 创建的共享内存段在进程退出后仍然存在，需要显式 shmctl(shmid, IPC_RMID, NULL) 删除，否则会导致资源泄漏。长期运行的嵌入式系统中这个问题尤其突出。
Unix Socket 缓冲区大小。默认的 SO_RCVBUF 和 SO_SNDBUF 在高吞吐场景下可能不足，需通过 setsockopt 调整。但内核会将用户设置值翻倍，需注意实际生效值。

五、检查清单

已明确 IPC 的数据量级和实时性要求
共享内存方案已添加信号量或无锁同步机制
Unix Socket 启动时已处理旧 socket 文件残留
D-Bus 策略文件已配置最小必要权限
共享内存段在进程退出时已显式删除
已测试进程异常退出后的恢复路径
已评估 IPC 机制对系统内存的总开销
跨平台移植性已验证（如涉及 ARM/x86 差异）

六、小结

D-Bus、共享内存和 Unix Socket 在嵌入式 Linux 中各有明确的适用边界。选型时应回到具体的数据特征、实时性约束和维护成本上做判断，而非追求某种机制的”最优”。工程实践中，同一个系统往往需要混合使用多种 IPC：用共享内存处理高频传感器数据流，用 Unix Socket 承载控制指令，用 D-Bus 管理系统级服务。把每种机制用在它最擅长的位置，是嵌入式 IPC 设计的基本原则。