Unlocked_ioctl vs normal ioctl

В моей структуре файла driver_operations у меня есть:

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

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

Ответ 1

Эмм, я решил это. Также требуется изменить подпись функции device_ioctl. Нет параметра inode, и функция должна возвращаться долго. Как и в следующем патче:

-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)

Ответ 2

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

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

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

Ответ 3

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

[ПРЕДЛОЖЕНИЕ JANITOR] Переключите функции ioctl в → unlocked_ioctl

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