unlocked_ioctl vs正常的ioctl

在我的驱动程序的file_operations结构中,我有:

struct file_operations Fops = { read: device_read, write: device_write, unlocked_ioctl: device_ioctl, ... }; 

即没有使用ioctl字段。 这足以避免大内核锁,并进入device_ioctl()没有任何同步? 或者我必须更改代码的用户空间部分中的ioctl()调用吗?

Solutions Collecting From Web of "unlocked_ioctl vs正常的ioctl"

阅读这篇LWN文章: http : //lwn.net/Articles/119652/

也有一段时间在2.6.33和2.6.35之间(使用git-diff来找出哪个提交)内核现在WARN当只有.ioctl被定义。

这是一个更加明确和细致的锁定的举措。 还要注意,只有改变函数签名和指针才能编译,但会引入竞争条件(两个用户空间应用程序在同一时间执行ioctl调用)的可能性。

Andi Kleem发布了一个在Linux内核邮件列表中使用ioctlunlocked_ioctl转换为代码的快捷方式:

[JANITOR建议]将ioctl函数切换到 – > unlocked_ioctl

配方解释了如何调整函数的参数并插入锁定和解锁调用。

呃,我解决了这个问题。 还需要更改device_ioctl函数的签名。 没有inode参数,并且函数应该返回long。 就像在下面的补丁中一样:

 -static int st_ioctl(struct inode *inode, struct file *file, - unsigned int cmd_in, unsigned long arg) +static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg) { 

(来自: http : //linux.derkeiler.com/Mailing-Lists/coreel/2008-01/msg06799.html )