6.1. ioctl 接口.pdfVIP

6.1. ioctl 接⼜ 6.1. ioctl 接⼜ ⼤部分驱动需要 -- 除了读写设备的能⼒ -- 通过设备驱动进⾏各种硬件控制的能⼒. ⼤ 部分设备可进⾏超出简单的 据传输之外的操作; ⽤户空间必须常常能够请求, 例如, 设备锁上它的门, 弹出它的介质, 报告错误信息, 改变波特率, 或者⾃我销毁. 这些操作 常常通过 ioctl ⽅法来⽀持, 它通过相同名⼦的系统调⽤来实现. 在⽤户空间, ioctl 系统调⽤有下⾯的原型: int ioctl(int fd, unsigned long cmd, ...); 这个原型由于这些点⽽凸现于 Unix 系统调⽤列表, 这些点常常表⽰函 有 ⽬不定的 参 . 在实际系统中, 但是, ⼀个系统调⽤不能真正有变 ⽬的参 . 系统调⽤必须有⼀ 个很好定义的原型, 因为⽤户程序可存取它们只能通过硬件的门. 因此, 原型中的点不 表⽰⼀个变 ⽬的参 , ⽽是⼀个单个可选的参 , 传统上标识为 char *argp . 这些点在 那⾥只是为了阻⽌在编译时的类型检查. 第 3 个参 的实际特点依赖所发出的特定的 控制命令( 第 2 个参 ) . ⼀些命令不⽤参 , ⼀些⽤⼀个整 值, 以及⼀些使⽤指向其 他 据的指针. 使⽤⼀个指针是传递任意 据到 ioctl 调⽤的⽅法; 设备接着可与⽤户空 间交换任何 量的 据. ioctl 调⽤的⾮结构化特性使它在内核开发者中失宠. 每个 ioctl 命令, 基本上, 是⼀个单 独的, 常常⽆⽂档的系统调⽤, 并且没有⽅法以任何类型的全⾯的⽅式核查这些调⽤. 也难于使⾮结构化的 ioctl 参 在所有系统上⼀致⼯作; 例如, 考虑运⾏在 32-位模式的 ⼀个⽤户进程的 64-位 系统. 结果, 有很⼤的压⼒来实现混杂的控制操作, 只通过任何其 他的⽅法. 可能的选择包括嵌⼊命令到 据流(本章稍后我们将讨论这个⽅法)或者使⽤ 虚拟⽂件系统, 要么是 sysfs 要么是设备特定的⽂件系统. (我们将在 14 章看看 sysfs) . 但是, 事实是 ioctl 常常是最容易的和最直接的选择,对于真正的设备操作. ioctl 驱动⽅法有和⽤户空间版本不同的原型: int (*ioctl) (struct inode *inode, struct file *filp, unsigned int ino e 和 filp 指针是对应应⽤程序传递的⽂件描述符 f 的值, 和传递给 open ⽅法的相 同参 . cm 参 从⽤户那⾥不改变地传下来, 并且可选的参 arg 参 以⼀个 unsigne long 的形式传递, 不管它是否由⽤户给定为⼀个整 或⼀个指针. 如果调⽤程 序不传递第 3 个参 , 被驱动操作收到的 arg 值是⽆定义的. 因为类型检查在这个额外 参 上被关闭, 编译器不能警告你如果⼀个⽆效的参 被传递给 ioctl , 并且任何关联的 错误将难以查找. 如果你可能想到的, ⼤部分 ioctl 实现包括⼀个⼤的 switch 语句来根据 cm 参 , 选择 正确的做法. 不同的命令有不同的 值, 它们常常被给予符号名来简化编码. 符号名通 过⼀个预处理定义来安排. 定制的驱动常常声明这样的符号在它们的头⽂件中; scull .h 为 scull 声明它们. ⽤户程序必须, 当然, 包含那个头⽂件来存取这些符号. 6.1.1. 选择 ioctl 命令 在为 ioctl 编写代码之前, 你需要选择对应命令的 字. 许多程序员的第⼀个本能的反应 是选择⼀组⼩ 从0或1开始, 并且从此开始向上. 但是, 有充分的理由不这样做. ioctl 命 令 字应当在这个系统是唯⼀的, 为了阻⽌向错误的设备发出正确的命令⽽引起的错 误. 这样的不匹配不会不可能发⽣, 并且⼀个程序可能发现它⾃⼰试图改变⼀个⾮串⼜ 输⼊系统的波特率, 例如⼀个 FIFO 或者⼀个⾳频设备. 如果这样的 ioctl 号是唯⼀的, 这个应⽤程序得到⼀个 EINVAL 错误⽽不是继续做不应当做的事情. 为帮助程序员创建唯⼀的 ioctl 命令代码, 这些编码已被划分为⼏个位段. Linux 的第⼀ 个版本使⽤ 16-位 : ⾼ 8 位是关联这个设备的魔 , 低 8 位是⼀个顺序号, 在设备内 唯⼀. 这样做是因为 Linus 是⽆能的(他⾃⼰的话); ⼀个更好的位段划分仅在后来被设 想. 不幸的是, 许多驱动仍然使⽤⽼传统. 它们不得不: 改变命令编码会破坏⼤