разблокированы функции ioctl против нормальной функции ioctl

в структуре file_operations моего драйвера у меня есть:

struct file_operations Fops = {
  read:    device_read,
  write:   device_write,
  unlocked_ioctl:   device_ioctl,
  ...
};

т. е. поле ioctl не используется. Достаточно ли этого, чтобы избежать большой блокировки ядра и войти в device_ioctl() без какой-либо синхронизации? Или мне тоже нужно изменить вызовы ioctl () в пользовательском пространстве?

3 ответов


прочитайте эту статью LWN: http://lwn.net/Articles/119652/

также где-то между 2.6.33 и 2.6.35 rc (используйте git-diff, чтобы узнать, какая фиксация) ядро теперь предупреждает, когда только .функции ioctl определяется.

Это движение в сторону более явной и мелкозернистой блокировки. Также обратите внимание, что только изменение сигнатуры функции и указателя будет компилироваться, но представит возможность условий гонки (два приложения userspace делают вызовы ioctl одновременно время.)


мм, я решил это. Также необходимо изменить сигнатуру функции 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)
{

(from:http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-01/msg06799.html)


Andi Kleem опубликовал рецепт быстрого и грязного преобразования кода с помощью ioctl до unlocked_ioctl в списке рассылки ядра Linux:

[предложение дворника] переключить функции ioctl на ->unlocked_ioctl

рецепт объясняет, как настроить параметры функции и вставить блокировку и разблокировку вызовов.