разблокированы функции 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
рецепт объясняет, как настроить параметры функции и вставить блокировку и разблокировку вызовов.