解锁的ioctl与正常ioctl

在我的驱动程序文件操作结构中，我有：

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

---

也就是说，没有使用ioctl字段。这足以避免大内核锁并在没有任何同步的情况下进入设备_ioctl（）吗？或者我也必须改变代码中用户空间部分的ioctl（）调用吗？

嗯，我解决了这个问题。还需要更改设备_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)
{

（发件人：）

阅读这篇LWN文章：

另外，在2.6.33和2.6.35 rc之间的某个时间（使用git diff找出哪个提交），内核现在会在仅定义.ioctl时发出警告

---

这是朝着更明确、更细粒度的锁定的方向发展。另请注意，仅更改函数签名和指针将编译，但会引入竞争条件的可能性（两个用户空间应用程序同时执行ioctl调用）。

Andi Kleem在Linux内核邮件列表上发布了一个使用

ioctl

到

unlocked\u ioctl

的快速脏代码转换方法：

---

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

这真的是有效的语法吗？它应该更像

.read=device\u read，

等。@ephemient:The

name:value

语法是一个旧的gcc扩展，在C99使用当前的

.name=value

语法添加指定的初始值设定项之前实现。@KeithThompson谢谢，我在这里找到了更多信息：（非C99语法自gcc 2.5以来已经过时）.截至2.6.38（可能更早），.ioctl已消失。您现在别无选择，只能使用.unlocked_ioctl。