这是程序员在设计一个设备驱动时必须做的一个选择之一, 并且正确的答案依赖正被解决 的实际问题.
对 EBUSY 的替代, 如同你可能已经想到的, 是实现阻塞 open. scullwuid 设备是一个在 打开时等待设备而不是返回 -EBUSY 的 sculluid 版本. 它不同于 sculluid 只在下面的 打开操作部分:
spin_lock(&scull_w_lock); while (! scull_w_available())
{
spin_unlock(&scull_w_lock);
if (filp->f_flags & O_NONBLOCK) return -EAGAIN;
if (wait_event_interruptible (scull_w_wait, scull_w_available())) return -ERESTARTSYS; /* tell the fs layer to handle it */
spin_lock(&scull_w_lock);
}
if (scull_w_count == 0)
scull_w_owner = current->uid; /* grab it */ scull_w_count++;
spin_unlock(&scull_w_lock);
这个实现再次基于一个等待队列. 如果设备当前不可用, 试图打开它的进程被放置到等待 队列直到拥有进程关闭设备.
release 方法, 接着, 负责唤醒任何挂起的进程:
static int scull_w_release(struct inode *inode, struct file *filp)
{
int temp; spin_lock(&scull_w_lock); scull_w_count--;
temp = scull_w_count; spin_unlock(&scull_w_lock);
if (temp == 0)
wake_up_interruptible_sync(&scull_w_wait); /* awake other uid's */ return 0;
}
这是一个例子, 这里调用 wake_up_interruptible_sync 是有意义的. 当我们做这个唤醒, 我们只是要返回到用户空间, 这对于系统是一个自然的调度点. 当我们做这个唤醒时不是 潜在地重新调度, 最好只是调用 "sync" 版本并且完成我们的工作.
阻塞式打开实现的问题是对于交互式用户真的不好, 他们不得不猜想哪里出错了. 交互式 用户常常调用标准命令, 例如 cp 和 tar, 并且不能增加 O_NONBLOCK 到 open 调用. 有