3. 内核 ioctl 方法：驱动中 unlocked_ioctl 与 compat_ioctl 的区别与选择

在 Linux 内核的字符设备驱动中，ioctl 是用户空间与内核空间进行自定义控制交互的核心接口。随着内核版本的演进，ioctl 的实现方法经历了从 ioctl 到 unlocked_ioctl 的变迁，并引入了 compat_ioctl 以解决 32/64 位兼容性问题。理解这两者的区别与正确选择，是编写健壮、可移植驱动的关键。

3.1 从 ioctl 到 unlocked_ioctl 的演进

在 Linux 2.6.36 之前，驱动通过 struct file_operations 中的 ioctl 方法实现控制接口。该方法在调用时会持有大内核锁（Big Kernel Lock, BKL），导致多核系统下的性能瓶颈。从 2.6.36 开始，内核引入了 unlocked_ioctl，它不再依赖 BKL，驱动开发者需要自行管理并发访问。

下图展示了 file_operations 结构体中 ioctl 相关方法的演变关系：

3.2 unlocked_ioctl 与 compat_ioctl 的核心区别

下表从多个维度详细对比了 unlocked_ioctl 和 compat_ioctl 的差异：

3.3 如何选择与实现

在实际驱动开发中，选择策略遵循以下原则：

1. 默认实现 unlocked_ioctl：所有新驱动必须实现此方法，它是 ioctl 功能的主入口。
2. 按需实现 compat_ioctl：仅当驱动需要运行在 64 位内核上，且可能被 32 位用户空间程序访问时，才需要实现。
3. 避免使用旧版 ioctl：除非驱动需要兼容非常古老的内核（< 2.6.36），否则不应使用。

3.4 compat_ioctl 的典型实现模式

当需要处理 32/64 位兼容时，最常用的策略是让 compat_ioctl 调用 unlocked_ioctl，前提是命令号本身不涉及指针大小差异。对于涉及结构体的命令，则需要单独处理。

以下是一个典型的实现框架：

/* 驱动中的 file_operations 定义 */
static const struct file_operations my_fops = {
    .owner          = THIS_MODULE,
    .unlocked_ioctl = my_unlocked_ioctl,
    .compat_ioctl   = my_compat_ioctl,  /* 32位兼容入口 */
    /* ... 其他操作 ... */
};

/* unlocked_ioctl 主实现 */
static long my_unlocked_ioctl(struct file *filp, unsigned int cmd,
                              unsigned long arg)
{
    struct my_device *dev = filp->private_data;
    int ret = 0;

    /* 使用互斥体保护共享资源 */
    mutex_lock(&dev->lock);

    switch (cmd) {
    case MY_IOCTL_GET_INFO:
        ret = my_get_info(dev, (void __user *)arg);
        break;
    case MY_IOCTL_SET_CONFIG:
        ret = my_set_config(dev, (void __user *)arg);
        break;
    default:
        ret = -ENOTTY;
        break;
    }

    mutex_unlock(&dev->lock);
    return ret;
}

/* compat_ioctl 实现：直接转发给 unlocked_ioctl */
static long my_compat_ioctl(struct file *filp, unsigned int cmd,
                            unsigned long arg)
{
    /* 对于不涉及指针大小差异的命令，直接转发 */
    return my_unlocked_ioctl(filp, cmd, arg);
}

3.5 处理 32/64 位结构体差异

当 ioctl 命令涉及的结构体在 32 位和 64 位系统上布局不同时（例如包含 long、指针或对齐填充），需要定义对应的 32 位兼容结构体，并在 compat_ioctl 中进行转换。

下图展示了数据转换的流程：

以下是一个处理结构体差异的代码示例：

/* 64位原生结构体 */
struct my_data {
    __u32   id;        /* 4 字节 */
    __u32   pad;       /* 填充，保证 8 字节对齐 */
    __u64   addr;      /* 8 字节 */
    __u32   len;       /* 4 字节 */
};

/* 32位兼容结构体（无填充） */
struct my_data32 {
    __u32   id;        /* 4 字节 */
    __u32   addr_hi;   /* 高 32 位地址 */
    __u32   addr_lo;   /* 低 32 位地址 */
    __u32   len;       /* 4 字节 */
};

/* compat_ioctl 中的转换处理 */
static long my_compat_ioctl(struct file *filp, unsigned int cmd,
                            unsigned long arg)
{
    struct my_data32 __user *u32 = (void __user *)arg;
    struct my_data kdata;
    struct my_data32 kdata32;

    switch (cmd) {
    case MY_IOCTL_SET_DATA:
        /* 从用户空间拷贝 32 位结构体 */
        if (copy_from_user(&kdata32, u32, sizeof(kdata32)))
            return -EFAULT;

        /* 转换为 64 位结构体 */
        kdata.id   = kdata32.id;
        kdata.addr = ((__u64)kdata32.addr_hi << 32) | kdata32.addr_lo;
        kdata.len  = kdata32.len;

        /* 调用内部处理函数 */
        return my_set_data(filp, &kdata);

    default:
        /* 对于不涉及结构体的命令，直接转发 */
        return my_unlocked_ioctl(filp, cmd, arg);
    }
}

3.6 最佳实践与避坑指南

• 命令号设计：使用 _IOR/_IOW/_IOWR 宏生成命令号，确保方向、大小和幻数正确，这有助于 compat 层自动处理部分兼容性。
• 统一处理入口：在 compat_ioctl 中优先尝试直接转发，仅对需要转换的命令做特殊处理，减少代码冗余。
• 避免指针直接传递：在 ioctl 命令中尽量使用固定大小的整数类型（__u32/__u64），避免直接传递指针，从根源上消除兼容性问题。
• 测试覆盖：在 32 位和 64 位用户空间程序下分别测试所有 ioctl 命令，确保 compat_ioctl 路径正确。
• 内核版本兼容：如果驱动需要支持 2.6.36 之前的内核，可以使用 #ifdef CONFIG_COMPAT 条件编译 compat 相关代码。

通过正确理解和实现 unlocked_ioctl 与 compat_ioctl，驱动开发者可以构建出既高效又兼容的 ioctl 接口，为上层应用提供稳定可靠的控制通道。