2. Binder 驱动基础：Binder 驱动在内核中的位置、设备节点 /dev/binder、驱动初始化流程

Binder 驱动是 Android 系统中 Binder IPC 机制在内核空间的核心实现。它作为一个字符设备驱动，运行在 Linux 内核中，负责管理进程间通信的数据传输、线程管理和对象引用计数。理解 Binder 驱动在内核中的位置、设备节点的作用以及驱动初始化流程，是掌握 Binder IPC 底层原理的第一步。

2.1 Binder 驱动在内核中的位置

Binder 驱动并非标准 Linux 内核的一部分，而是 Android 内核分支（Android Common Kernel / AOSP Kernel）中特有的驱动模块。它在内核源码树中的位置如下：

Binder 驱动在内核中的层次关系如下图所示：

2.2 设备节点 /dev/binder

Binder 驱动在用户空间通过字符设备节点 /dev/binder 暴露服务。用户空间的进程通过打开该设备节点，并使用 ioctl() 系统调用与 Binder 驱动进行交互。

2.2.1 设备节点创建方式

设备节点的创建有两种方式：

• 传统方式（devtmpfs / udev）： 驱动在初始化时注册设备号，由 devtmpfs 或 udev 自动在 /dev/ 目录下创建设备节点。主设备号通常为动态分配，次设备号为 0。
• binderfs 方式（推荐）： Android 4.4+ 引入了 binderfs 虚拟文件系统，可以挂载到 /dev/binderfs 目录，支持动态创建多个 Binder 设备节点（如 binder、binder-control、binder-hwbinder、binder-vndbinder），用于隔离不同域（framework、vendor、hardware）的通信。

2.2.2 设备节点权限

/dev/binder 设备节点的权限控制至关重要：

• 通常设置为 0666（全局可读写），因为所有应用进程都需要使用 Binder 进行 IPC。
• 在 SELinux 强制访问控制策略中，需要为不同域（如 untrusted_app、system_app）配置对应的 allow 规则，允许它们打开 Binder 设备节点。
• 使用 binderfs 时，每个设备节点可以设置不同的权限和 SELinux 上下文，实现更细粒度的访问控制。

2.3 驱动初始化流程

Binder 驱动的初始化流程从内核启动时开始，经历模块加载、设备注册、文件操作接口设置等步骤。以下是完整的初始化流程：

2.3.1 关键初始化函数分析

Binder 驱动的初始化入口函数是 binder_init()，定义在 drivers/android/binder.c 中。以下是核心代码片段：

static int __init binder_init(void)
{
    int ret;
    struct binder_device *device;

    // 1. 分配字符设备区域（主设备号）
    ret = alloc_chrdev_region(&binder_first_dev, 0, BINDER_MAX_DEVICES,
                              "binder");
    if (ret < 0)
        return ret;

    // 2. 为每个 Binder 设备初始化 cdev 并添加到内核
    list_for_each_entry(device, &binder_devices, entry) {
        cdev_init(&device->cdev, &binder_fops);
        device->cdev.owner = THIS_MODULE;

        ret = cdev_add(&device->cdev,
                       MKDEV(MAJOR(binder_first_dev), device->minor), 1);
        if (ret < 0)
            goto err_cdev_add;

        // 3. 创建设备类
        device->class = class_create(THIS_MODULE, device->name);
        if (IS_ERR(device->class)) {
            ret = PTR_ERR(device->class);
            goto err_class_create;
        }

        // 4. 创建设备节点
        device->device = device_create(device->class, NULL,
                                       MKDEV(MAJOR(binder_first_dev),
                                             device->minor),
                                       NULL, "%s", device->name);
        if (IS_ERR(device->device)) {
            ret = PTR_ERR(device->device);
            goto err_device_create;
        }
    }

    // 5. 如果启用了 binderfs，则初始化 binderfs
    ret = init_binderfs();
    if (ret < 0)
        goto err_init_binderfs;

    return 0;

    // 错误处理（略）
}

2.3.2 文件操作接口（binder_fops）

Binder 驱动通过 binder_fops 结构体向 VFS 层注册文件操作函数，用户空间通过 open()、ioctl()、mmap()、poll() 等系统调用触发这些函数：

2.4 驱动初始化后的内核数据结构

初始化完成后，Binder 驱动在内核中维护以下核心数据结构：

• binder_proc： 每个打开 /dev/binder 的进程对应一个 binder_proc 结构，包含进程 PID、线程列表、待处理事务队列、已映射缓冲区等信息。
• binder_thread： 每个参与 Binder 通信的线程对应一个 binder_thread 结构，包含线程 ID、事务栈、等待队列等。
• binder_node： 每个注册到 Binder 驱动的服务（Binder 实体）对应一个 binder_node 结构，包含引用计数、调试 ID 等。
• binder_ref： 每个进程持有的远程 Binder 引用对应一个 binder_ref 结构，包含指向 binder_node 的指针和本地引用描述符。
• binder_transaction： 每个正在处理或等待处理的事务对应一个 binder_transaction 结构，包含发送方、接收方、数据缓冲区、工作队列等。

2.5 调试与验证

在开发和调试 Binder 驱动时，可以通过以下方式验证驱动是否正确加载和初始化：

• 检查设备节点： ls -l /dev/binder 或 ls -l /dev/binderfs/，确认设备节点存在且权限正确。
• 查看内核模块： lsmod | grep binder，确认 binder 模块已加载。
• 查看内核日志： dmesg | grep binder，查看驱动初始化过程中的打印信息。
• 查看 procfs 信息： cat /proc/binder/proc（如果内核启用了 CONFIG_ANDROID_BINDER_IPC_DEBUG），查看当前 Binder 进程列表。
• 使用 binderfs 调试： 挂载 binderfs 后，可以通过 cat /dev/binderfs/binder-control 查看设备信息。