在我的驾驶file_operations结构，我有：
struct file_operations Fops = {
read: device_read,
write: device_write,
unlocked_ioctl: device_ioctl,
...
};
即没有使用任何的ioctl领域。 这是足以避免大内核锁，并没有任何同步进入device_ioctl（）？ 还是我改变的ioctl（）调用的代码太的用户空间的一部分吗？
Answer 1:
阅读这篇文章LWN： http://lwn.net/Articles/119652/
2.6.33和2.6.35一个RC之间也有时（使用git-diff命令来找出哪些提交）仅被定义.ioctl当内核现在警告。
这是朝着更加明确和细粒度锁的举动。 还要注意只改变函数签名和指针将编译，但会引入竞争条件的可能性（二用户空间应用程序在做的同时控制调用）。
Answer 2:
嗯，我解决了这个。 它也需要改变device_ioctl功能的签名。 有没有inode的参数，也是函数应返回长。 就像在以下修补程序：
-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/Kernel/2008-01/msg06799.html ）
Answer 3:
安迪Kleem张贴的使用代码的快速和肮脏的转换配方ioctl来unlocked_ioctl Linux内核邮件列表：
[JANITOR提案]切换的ioctl功能- > unlocked_ioctl
配方说明如何调整函数的参数，并插入锁定和解锁电话。
文章来源: unlocked_ioctl vs normal ioctl
