問題解析：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對應的系統(tǒng)調用接口沒有變化，所以用戶程序不需要改變，一切都交給內核處理了，如果想在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系統(tǒng)調用往后，真正的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 開發(fā)者正在試圖朝移除大內核鎖的方向努力，ioctl的移除就是被革命了。相信以后越來越多的內核函數會擺脫大內核鎖的依賴，并且大內核鎖最終會被移除。