高级字符驱动程序（1）

高级字符驱动程序操作

《Linux设备驱动程序（第3版）》第六章和《Linux设备驱动开发详解》

这一节将讲到以下内容：

ioctl 接口

阻塞与非阻塞IO

poll 和 select

异步通知与异步IO

移位一个设备

 

一、ioctl 接口

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

在用户空间, ioctl 系统调用有下面的原型:

int ioctl(int fd, unsigned long cmd, ...); 

这些点常常表示函数有数目不定的参数。

ioctl 驱动方法有和用户空间版本不同的原型:

int (*ioctl) (struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg);

inode 和 filp 指针是对应应用程序传递的文件描述符 fd 的值, 和传递给 open 方法的相同参数. cmd 参数从用户那里不改变地传下来, 并且可选的参数 arg 参数以一个 unsigned long 的形式传递, 不管它是否由用户给定为一个整数或一个指针. 如果调用程序不传递第 3 个参数, 被驱动操作收到的 arg 值是无定义的. 因为类型检查在这个额外参数上被关闭, 编译器不能警告你如果一个无效的参数被传递给 ioctl, 并且任何关联的错误将难以查找.

 

选择 ioctl 命令

为了防止向错误的设备使用正确的命令，命令号应该在系统范围内唯一。为方便程序员创建唯一的 ioctl 命令代号， 每个命令号被划分为多个位字段。要按 Linux 内核的约定方法为驱动选择 ioctl 的命令号, 应该首先看看 include/asm/ioctl.h 和 Documentation/ioctl-number.txt。 要使用的位字段符号定义在 :

定义 ioctl 命令号的正确方法使用 4 个位段, 它们有下列的含义. 这个列表中介绍的新符号定义在 .

type

魔数. 只是选择一个数(在参考了 ioctl-number.txt之后)并且使用它在整个驱动中. 这个成员是 8 位宽(_IOC_TYPEBITS).

number

序(顺序)号. 它是 8 位(_IOC_NRBITS)宽.

direction

数据传送的方向,如果这个特殊的命令涉及数据传送. 可能的值是 _IOC_NONE(没有数据传输), _IOC_READ, _IOC_WRITE, 和 _IOC_READ|_IOC_WRITE (数据在2个方向被传送). 数据传送是从应用程序的观点来看待的; _IOC_READ 意思是从设备读, 因此设备必须写到用户空间. 注意这个成员是一个位掩码, 因此 _IOC_READ 和 _IOC_WRITE 可使用一个逻辑 AND 操作来抽取.

size

涉及到的用户数据的大小. 这个成员的宽度是依赖体系的, 但是常常是 13 或者 14 位. 你可为你的特定体系在宏 _IOC_SIZEBITS 中找到它的值. 你使用这个 size 成员不是强制的 - 内核不检查它 -- 但是它是一个好主意. 正确使用这个成员可帮助检测用户空间程序的错误并使你实现向后兼容, 如果你曾需要改变相关数据项的大小. 如果你需要更大的数据结构, 但是, 你可忽略这个 size 成员. 我们很快见到如何使用这个成员.

头文件 , 它包含在 中, 定义宏来帮助建立命令号, 如下:

_IO(type,nr)(给没有参数的命令),

_IOR(type, nre, datatype)(给从驱动中读数据的),

_IOW(type,nr,datatype)(给写数据),

_IOWR(type,nr,datatype)(给双向传送)，

type 和 number 成员作为参数被传递, 并且 size 成员通过应用 sizeof 到 datatype 参数而得到.

这个头文件还定义宏, 可被用在你的驱动中来解码这个号:

_IOC_DIR(nr),

_IOC_TYPE(nr),

_IOC_NR(nr),

_IOC_SIZE(nr). 我们不进入任何这些宏的细节, 因为头文件是清楚的。

返回值

POSIX 标准：

如果一个不合适的 ioctl 命令被发出, 那么 -ENOTTY 应当被返回. 这个错误码被 C 库解释为"设备的不适当的 ioctl", 这常常正是程序员需要听到的. 然而, 它仍然是相当普遍的来返回 -EINVAL, 对于响应一个无效的 ioctl 命令.

 

预定义命令

有一些ioctl命令是由内核识别的，当这些命令用于自己的设备时，他们会在我们自己的文件操作被调用之前被解码. 因此, 如果你选择一个ioctl命令编号和系统预定义的相同时，你永远不会看到该命令的请求，而且因为ioctl 号之间的冲突，应用程序的行为将无法预测。预定义命令分为 3 类:

（1）用于任何文件(常规, 设备, FIFO和socket) 的命令

（2）只用于常规文件的命令

（3）特定于文件系统类型的命令 

下列 ioctl 命令是预定义给任何文件，包括设备特定文件：

FIOCLEX ：设置 close-on-exec 标志(File IOctl Close on EXec)。

FIONCLEX ：清除 close-no-exec 标志(File IOctl Not CLose on EXec)。

FIOQSIZE ：这个命令返回一个文件或者目录的大小; 当用作一个设备文件, 但是, 它返回一个 ENOTTY 错误。

FIONBIO："File IOctl Non-Blocking I/O"(在"阻塞和非阻塞操作"一节中描述)。 

 

使用ioctl参数

在使用ioctl的可选arg参数时，如果传递的是一个整数，它可以直接使用。如果是一个指针,，就必须小心。当用一个指针引用用户空间, 我们必须确保用户地址是有效的，其校验(不传送数据)由函数 access_ok 实现，定义在 :

int access_ok(int type, const void *addr, unsigned long size);

第一个参数应当是 VERIFY_READ（读）或VERIFY_WRITE（读写）；addr 参数为用户空间地址，size 为字节数，可使用sizeof()。access_ok 返回一个布尔值: 1 是成功(存取没问题)和 0 是失败(存取有问题)。如果它返回假，驱动应当返回 -EFAULT 给调用者。

注意：首先, access_ok不做校验内存存取的完整工作; 它只检查内存引用是否在这个进程有合理权限的内存范围中，且确保这个地址不指向内核空间内存。其次，大部分驱动代码不需要真正调用 access_ok，而直接使用put_user(datum, ptr)和get_user(local, ptr)，它们带有校验的功能，确保进程能够写入给定的内存地址，成功时返回 0, 并且在错误时返回 -EFAULT.。

put_user(datum, ptr)
__put_user(datum, ptr)
get_user(local, ptr)
__get_user(local, ptr)

这些宏它们相对copy_to_user 和copy_from_user快, 并且这些宏已被编写来允许传递任何类型的指针，只要它是一个用户空间地址. 传送的数据大小依赖 prt 参数的类型, 并且在编译时使用 sizeof 和 typeof 等编译器内建宏确定。他们只传送1、2、4或8 个字节。如果使用以上函数来传送一个大小不适合的值，结果常常是一个来自编译器的奇怪消息，如"coversion to non-scalar type requested". 在这些情况中，必须使用 copy_to_user 或者 copy_from_user。

__put_user和__get_user 进行更少的检查(不调用 access_ok), 但是仍然能够失败如果被指向的内存对用户是不可写的，所以他们应只用在内存区已经用 access_ok 检查过的时候。作为通用的规则：当实现一个 read 方法时，调用 __put_user 来节省几个周期, 或者当你拷贝几个项时，因此，在第一次数据传送之前调用 access_ok 一次。

权能与受限操作

Linux 内核提供了一个更加灵活的系统, 称为权能（capability）。内核专为许可管理上使用权能并导出了两个系统调用 capget 和 capset，这样可以从用户空间管理权能，其定义在  中。对设备驱动编写者有意义的权能如下:

CAP_DAC_OVERRIDE /*越过在文件和目录上的访问限制(数据访问控制或 DAC)的能力。*/
CAP_NET_ADMIN /*进行网络管理任务的能力, 包括那些能够影响网络接口的任务*/

CAP_SYS_MODULE /*加载或去除内核模块的能力*/

CAP_SYS_RAWIO /*进行 "raw"（裸）I/O 操作的能力. 例子包括存取设备端口或者直接和 USB 设备通讯*/

CAP_SYS_ADMIN /*截获的能力, 提供对许多系统管理操作的途径*/

CAP_SYS_TTY_CONFIG /*执行 tty 配置任务的能力*/

在进行一个特权操作之前, 一个设备驱动应当检查调用进程有合适的能力,检查是通过 capable 函数来进行的(定义在 )范例如下:

if (! capable (CAP_SYS_ADMIN))
 return -EPERM;

 

二、阻塞与非阻塞IO

阻塞的引入：

在实现read 和 write 方法上，会出现这样的情况：

一个驱动当它无法立刻满足请求应当如何响应? 一个对 read 的调用可能当没有数据时到来, 而以后会期待更多的数据. 或者一个进程可能试图写, 但是你的设备没有准备好接受数据, 因为你的输出缓冲满了. 调用进程往往不关心这种问题; 程序员只希望调用 read 或 write 并且使调用返回, 在必要的工作已完成后. 这样, 在这样的情形中, 你的驱动应当(缺省地)阻塞进程, 使它进入睡眠直到请求可继续。

 

在展示如何使一个进程睡眠并且之后再次唤醒它之前，我们必须首先解释几个概念：

睡眠的介绍

对于一个进程"睡眠"意味着什么? 当一个进程被置为睡眠, 它被标识为处于一个特殊的状态并且从调度器的运行队列中去除. 直到发生某些事情改变了那个状态, 这个进程将不被在任何 CPU 上调度, 并且, 因此, 将不会运行. 一个睡着的进程已被搁置到系统的一边, 等待以后发生事件.

对于一个 Linux 驱动使一个进程睡眠是一个容易做的事情. 但是, 有几个规则必须记住以安全的方式编码睡眠.

（1） 永远不要在原子上下文中进入休眠，即当驱动在持有一个自旋锁、seqlock或者 RCU 锁时不能睡眠；关闭中断也不能睡眠。持有一个信号量时休眠是合法的，但你应当仔细查看代码：如果代码在持有一个信号量时睡眠，任何其他的等待这个信号量的线程也会休眠。因此发生在持有信号量时的休眠必须短暂，而且决不能阻塞那个将最终唤醒你的进程。

（2）当进程被唤醒，它并不知道休眠了多长时间以及休眠时发生什么；也不知道是否另有进程也在休眠等待同一事件，且那个进程可能在它之前醒来并获取了所等待的资源。所以不能对唤醒后的系统状态做任何的假设，并必须重新检查等待条件来确保正确的响应。

除非确信其他进程会在其他地方唤醒休眠的进程，否则也不能睡眠。使进程可被找到意味着：需要维护一个称为等待队列的数据结构。它是一个进程链表，其中饱含了等待某个特定事件的所有进程。在 Linux 中， 一个等待队列由一个wait_queue_head_t 结构体来管理，其定义在中。wait_queue_head_t 类型的数据结构非常简单：

struct __wait_queue_head {
    spinlock_t lock;
    struct list_head task_list;
};
typedef struct __wait_queue_head wait_queue_head_t;

它包含一个自旋锁和一个链表。这个链表是一个等待队列入口，它被声明做 wait_queue_t。wait_queue_head_t包含关于睡眠进程的信息和它想怎样被唤醒。

 简单睡眠

当一个进程睡眠, 它这样做以期望某些条件在以后会成真. 如我们之前注意到的, 任何睡眠的进程必须在它再次醒来时检查来确保它在等待的条件真正为真. Linux 内核中睡眠的最简单方式是一个宏定义, 称为 wait_event(有几个变体); 它结合了处理睡眠的细节和进程在等待的条件的检查. wait_event 的形式是:

wait_event(queue, condition)

wait_event_interruptible(queue, condition)

wait_event_timeout(queue, condition, timeout)

wait_event_interruptible_timeout(queue, condition, timeout)

在所有上面的形式中, queue 是要用的等待队列头. 注意它是"通过值"传递的. 条件是一个被这个宏在睡眠前后所求值的任意的布尔表达式; 直到条件求值为真值, 进程继续睡眠. 注意条件可能被任意次地求值, 因此它不应当有任何边界效应.

如果你使用 wait_event, 你的进程被置为不可中断地睡眠, 如同我们之前已经提到的, 它常常不是你所要的. 首选的选择是 wait_event_interruptible, 它可能被信号中断. 这个版本返回一个你应当检查的整数值; 一个非零值意味着你的睡眠被某些信号打断, 并且你的驱动可能应当返回 -ERESTARTSYS. 最后的版本(wait_event_timeout 和 wait_event_interruptible_timeout)等待一段有限的时间; 在这个时间期间(以嘀哒数表达的, 我们将在第 7 章讨论)超时后, 这个宏返回一个 0 值而不管条件是如何求值的.

图片的另一半, 当然, 是唤醒. 一些其他的执行线程(一个不同的进程, 或者一个中断处理, 也许)必须为你进行唤醒, 因为你的进程, 当然, 是在睡眠. 基本的唤醒睡眠进程的函数称为 wake_up. 它有几个形式(但是我们现在只看其中 2 个):

void wake_up(wait_queue_head_t *queue);

void wake_up_interruptible(wait_queue_head_t *queue);

wake_up 唤醒所有的在给定队列上等待的进程(尽管这个情形比那个要复杂一些, 如同我们之后将见到的). 其他的形式(wake_up_interruptible)限制它自己到处理一个可中断的睡眠. 通常, 这 2 个是不用区分的(如果你使用可中断的睡眠); 实际上, 惯例是使用 wake_up 如果你在使用 wait_event , wake_up_interruptible 如果你在使用 wait_event_interruptible.

阻塞和非阻塞的定义：

阻塞：阻塞操作是指在执行设备操作时若不能获得资源则挂起进程，直到满足可操作的条件后再进行操作，被挂起的进程进入休眠状态，被从调度器的运行队列移走，直到等待的条件被满足。

非阻塞：

非阻塞操作的进程在不能进行设备操作时并不挂起，它或者放弃，或者不停的查询，直至可以进行操作为止。

 

阻塞从字面上听起来似乎意味着效率低下，实则不然，如果设备驱动不阻塞，则用户想获取设备资源只能不停的查询，这反而会无谓的耗费CPU资源，而阻塞访问时，不能获取资源的进程将进入休眠，它将CPU资源让给其它进程。

因为阻塞的进程会进入休眠状态，因此，必须确保有一个地方能够唤醒休眠的进程，唤醒进程最大的地方最大可能发生在中断里面，因为硬件资源获得的同时往往伴随着一个中断。

 

在linux驱动中，可以用等待队列（wait queue）来实现阻塞进程的唤醒，等待队列可以用来同步对系统资源的访问，之前的讲的信号量在内核中也依赖等待队列来实现。

全功能的 read 和 write 方法涉及到进程可以决定是进行非阻塞 I/O还是阻塞 I/O操作。明确的非阻塞 I/O 由 filp->f_flags 中的 O_NONBLOCK 标志来指示（定义再 ，被 自动包含）。浏览源码，会发现O_NONBLOCK 的另一个名字：O_NDELAY ，这是为了兼容 System V 代码。O_NONBLOCK 标志缺省地被清除，因为等待数据的进程的正常行为只是睡眠.

其实不一定只有read 和 write 方法有阻塞操作，open也可以有阻塞操作。

讲到阻塞必须要详细说到等待队列的概念和各种操作，有关内容可以参考linux内核里《Linux内核wait_queue深入分析》《Linux内核的等待队列》两篇文章。