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的移除就是被革命了。相信以後越來越多的核心功能會擺脫大核心鎖的依賴，並且大核心鎖最終會被移除。