大部分驱动需要 -- 除了读写设备的能力 -- 通过设备驱动进行各种硬件控制的能力. 大 部分设备可进行超出简单的数据传输之外的操作; 用户空间必须常常能够请求, 例如, 设 备锁上它的门, 弹出它的介质, 报告错误信息, 改变波特率, 或者自我销毁. 这些操作常 常通过 ioctl 方法来支持, 它通过相同名子的系统调用来实现.

在用户空间, ioctl 系统调用有下面的原型: int ioctl(int fd, unsigned long cmd, ...);

这个原型由于这些点而凸现于 Unix 系统调用列表, 这些点常常表示函数有数目不定的参 数. 在实际系统中, 但是, 一个系统调用不能真正有变数目的参数. 系统调用必须有一个 很好定义的原型, 因为用户程序可存取它们只能通过硬件的"门". 因此, 原型中的点不表 示一个变数目的参数, 而是一个单个可选的参数, 传统上标识为 char *argp. 这些点在 那里只是为了阻止在编译时的类型检查. 第 3 个参数的实际特点依赖所发出的特定的控 制命令( 第 2 个参数 ). 一些命令不用参数, 一些用一个整数值, 以及一些使用指向其 他数据的指针. 使用一个指针是传递任意数据到 ioctl 调用的方法; 设备接着可与用户 空间交换任何数量的数据.

ioctl 调用的非结构化特性使它在内核开发者中失宠. 每个 ioctl 命令, 基本上, 是一 个单独的, 常常无文档的系统调用, 并且没有方法以任何类型的全面的方式核查这些调用. 也难于使非结构化的 ioctl 参数在所有系统上一致工作; 例如, 考虑运行在 32-位模式 的一个用户进程的 64-位 系统. 结果, 有很大的压力来实现混杂的控制操作, 只通过任 何其他的方法. 可能的选择包括嵌入命令到数据流(本章稍后我们将讨论这个方法)或者使 用虚拟文件系统, 要么是 sysfs 要么是设备特定的文件系统. (我们将在 14 章看看 sysfs). 但是, 事实是 ioctl 常常是最容易的和最直接的选择,对于真正的设备操作.