unlocked_ioctl по сравнению с нормальным ioctl
Что касается , почему это все еще существует - MS не считает это приоритетом и ценит обратную совместимость по сравнению с продвижением своих ОС (по крайней мере, в этом случае).
Обходной путь, который я использую, состоит в том, чтобы использовать «короткие имена» для каталогов в пути, вместо их стандартных, удобочитаемых версий. Так например для C:\Program Files\ я бы использовал C:\PROGRA~1\. Вы можете найти эквиваленты короткого имени, используя dir /x.
2 ответа
Эээ, я решил это. Также необходимо изменить сигнатуру функции device_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)
{
(от: http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-01/msg06799.html )
Прочтите эту статью LWN: http://lwn.net/Articles/119652/
Также где-то между 2.6.33 и 2.6.35 rc (используйте git-diff, чтобы узнать, какой коммит) ядро теперь ПРЕДУПРЕЖДАЕТ, когда только .ioctl определенный.
Это шаг к более явной и детальной блокировке. Также обратите внимание, что при компиляции будет выполнено только изменение сигнатуры функции и указателя, но при этом возникнет вероятность состояния гонки (два приложения пользовательского пространства выполняют вызовы ioctl одновременно).