ioctl 变成了 unlocked_ioctl

kernel 2.6.35 及之前的版本中struct file_operations 一共有3个ioctl ：

ioctl,unlocked_ioctl和compat_ioctl

现在只有unlocked_ioctl和compat_ioctl 了

在kernel 2.6.36 中已经完全删除了struct file_operations 中的ioctl 函数指针，取而代之的是unlocked_ioctl 。

这个指针函数变了之后最大的影响是参数中少了inode ， 不过这个不是问题，因为用户程序中的ioctl对应的系统调用接口没有变化，所以用户程序不需要改变，一切都交给内核处理了，如果想在unlocked_ioctl中获得inode 等信息可以用如下方法：

struct inode *inode = file->f_mapping->host;

struct block_device *bdev = inode->i_bdev;

struct gendisk *disk = bdev->bd_disk;

fmode_t mode = file->f_mode;

struct backing_dev_info *bdi;

这次内核函数的变化引出了一个问题，从ioctl系统调用往后，真正的ioctl调用顺序是什么？为什么compat_ioctl 不被调用？

compat_ioctl被使用在用户空间为32位模式，而内核运行在64位模式时。这时候，需要将64位转成32位。

以下是2.6.36的情况：

   
   
   
   

    
    
    
    SYSCALL_DEFINE3(ioctl ...) compat_sys_ioctl (是否直接调用compat_ioctl 取决于compat_ioctl 是否存在)
   
   
   
   


   
   
   
   

    
    
    
     | | |-----> compat_ioctl
   
   
   
   


   
   
   
   

    
    
    
     |   |
   
   
   
   


   
   
   
   

    
    
    
     |------>do_vfs_ioctl (下一步的调用取决于file->f_path.dentry->d_inode->i_node)
   
   
   
   


   
   
   
   

    
    
    
     |            |------>file_ioctl
   
   
   
   


   
   
   
   

    
    
    
     | |
   
   
   
   


   
   
   
   

    
    
    
     |-------------------------------->vfs_ioctl
   
   
   
   


   
   
   
   

    
    
    
     |------->unlock_ioctl
   
   
   
   

其实compat_ioctl 没有被调用的原因是compat_sys_ioctl 没有被调用，而它没有被调用的原因似乎是压根就没有编译到内核中，因为我没有找到调用这个函数的代码。

unlocked_ioctl 实际上取代了用了很久的ioctl，主要的改进就是不再需要上大内核锁 （调用之前不再先调用lock_kernel()然后再unlock_kernel()）

总的来说kernel 开发者正在试图朝移除大内核锁的方向努力，ioctl的移除就是被革命了。相信以后越来越多的内核函数会摆脱大内核锁的依赖，并且大内核锁最终会被移除。

转载自：http://lp007819.wordpress.com/2011/01/06/kernel-2-6-36-ioctl-%E5%8F%98%E6%9B%B4/