linux open阻塞打开,linux 阻塞 open 作为对 EBUSY 的替代

这是程序员在设计一个设备驱动时必须做的一个选择之一, 并且正确的答案依赖正被解决 的实际问题.

对 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 调用. 有