1. ioctl 概述：系统调用的作用、与 read/write 的区别、在字符设备驱动中的位置
1.1 ioctl 系统调用的核心作用
在 Linux 字符设备驱动中，read() 和 write() 系统调用负责数据流的传输，但硬件设备往往需要配置参数、设置波特率、获取状态、执行复位等非数据流操作。ioctl（Input/Output Control）正是为这类“控制”与“配置”场景而设计的系统调用。
ioctl 的本质是一个多路复用接口：用户空间通过传入不同的命令码，驱动根据命令码执行对应的硬件操作。它填补了标准文件操作在设备控制层面的空白。
关键特性： ioctl 允许用户空间向设备驱动发送任意控制命令，并携带自定义参数，实现“一接口多命令”的灵活控制模型。
1.2 ioctl 与 read/write 的对比
下表从多个维度对比 ioctl 与 read/write 的差异，帮助理解各自的设计定位：
| 对比维度 | read / write | ioctl |
|---|---|---|
| 主要用途 | 数据流传输（连续、批量） | 设备控制、参数配置、状态查询 |
| 操作粒度 | 按字节/缓冲区分块读写 | 按命令码执行原子控制操作 |
| 参数传递 | 用户缓冲区指针 + 长度 | 命令码 + 可选参数（整数或指针） |
| 返回值语义 | 成功时返回传输字节数 | 成功时返回 0，失败返回 -1 并设置 errno |
| 驱动接口 | read() / write() 函数指针 |
unlocked_ioctl() 或 compat_ioctl() |
| 典型场景 | 传感器数据采集、音频流播放 | 设置串口波特率、GPIO 方向、设备复位 |
设计原则： 数据流用 read/write，控制流用 ioctl。混合使用会导致接口语义混乱，增加驱动维护成本。
1.3 ioctl 在字符设备驱动中的位置
字符设备驱动的核心是 struct file_operations 结构体，ioctl 作为其中的一个关键成员，与其他操作共同构成完整的驱动接口。下图展示了 ioctl 在驱动框架中的层级位置：
1.4 ioctl 在 file_operations 中的接口原型
在 Linux 内核中，ioctl 对应的驱动接口经历了演变。现代内核（2.6.36+）使用 unlocked_ioctl，其原型如下：
/* 内核驱动中 ioctl 的标准接口原型 */
long (*unlocked_ioctl)(struct file *filp, unsigned int cmd, unsigned long arg);
/* 参数说明：
* filp : 文件指针，指向打开的设备文件
* cmd : 用户空间传入的命令码（32位无符号整数）
* arg : 命令的附加参数（整数或用户空间指针）
*
* 返回值：成功返回 0，失败返回负的错误码（如 -EINVAL, -ENOTTY）
*/
注意： 旧内核中的
ioctl() 接口（使用 BKL 大内核锁）已被废弃。新驱动必须实现 unlocked_ioctl()，并在需要处理 32 位兼容时实现 compat_ioctl()。
1.5 ioctl 的典型工作流程
从用户空间发起 ioctl 调用到驱动执行硬件操作的完整路径如下：
- 用户空间调用：
int ret = ioctl(fd, CMD_SET_BAUD, &baudrate); - 系统调用入口： 内核通过
sys_ioctl()进入 VFS 层。 - VFS 分发： 根据文件描述符找到对应的
file结构，调用file->f_op->unlocked_ioctl()。 - 驱动处理： 驱动根据
cmd命令码，使用switch/case分发到具体硬件操作。 - 参数传递： 通过
copy_from_user()/copy_to_user()安全传递数据。 - 返回结果： 驱动返回 0（成功）或负错误码，用户空间通过
errno获取错误详情。
核心要点： ioctl 是用户空间与驱动之间“控制通道”的标准实现。理解其在整个驱动栈中的位置，是后续设计自定义命令码、实现参数传递、处理并发访问的基础。