уже не помню, я кажется, заюзал

unlocked_ioctl

а ещё после 36 выпилили big kernel lock :)

unlocked_ioctl

lazyklimm, ananas, спасибо!

Буду пробовать.

// а вообще, ох уж мне эти изменения: приходится иногда целый день убить, чтобы в новом дистрибутиве (или просто при обновлении ядра) заставить какую-нибудь железяку работать. А производители железа иногда вообще выкладывают модуль под 2.4.X и плевать они хотели, какая сейчас версия ядра актуальна...

Опа, идентификатора POLL_IN нет... Ищем дальше.

> а вообще, ох уж мне эти изменения: приходится иногда целый день убить, чтобы в новом дистрибутиве (или просто при обновлении ядра) заставить какую-нибудь железяку работать

знакомая ситуация. еще хуже, когда исходников вообще нет

asm/siginfo.h

Ну, если исходников нет вообще, то такая железяка просто не покупается.

> Ну, если исходников нет вообще, то такая железяка просто не покупается.

ыыы, если бы это только от меня зависело...

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

А производители железа иногда вообще выкладывают модуль под 2.4.X и плевать они хотели, какая сейчас версия ядра актуальна...

Вы так говорите, будто это что-то плохое. Благодаря таким вот вендорам и изменчивому API разработчики в этой нише не останутся без хлеба никогда :)

Спасибо, добавил в include, все ОК.

Хорошо, когда правка модуля ядра обходится такими малыми трудами.

Ну, у нас, т.к. я с этими железками работаю, то я их и выбираю =)

Скомпилировать-то модуль скомпилировался, но возникают ошибки в момент выполнения ioctl'ов:

 kernel:last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
 kernel:Process test7841 (pid: 7581, ti=e7eb2000 task=f4f057f0 task.ti=e7eb2000)
 kernel:Stack:
 kernel:Call Trace:
 kernel:Code: 4d ec 30 d2 c7 44 83 0c 00 00 00 00 8b 44 8b 04 29 d0 79 bf eb e1 90 55 89 e5 83 ec 1c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 <8b> 72 74 81 f9 13 53 0c 40 89 c7 89 d3 0f 84 51 01 00 00 0f 86 
 kernel:EIP: [<f9d68544>] p7841_ioctl+0x14/0x480 [p7841] SS:ESP 0068:e7eb3f00
 kernel:CR2: 00000000800c538a

lazyklimm, ananas, а не подскажете, что можно почитать по новинкам в ядре 2.6.38? Еще хотелось бы увидеть какое-нибудь руководство по изменению модулей ядра 2.6.31, чтобы они работали в 2.6.38.

Обнаружил, что помимо замены ioctl на unlocked_ioctl в структуре file_operations, необходимо еще и саму функцию-обработчик изменить (у нее теперь на 1 аргумент меньше).

И вот здесь возникли проблемы: первым аргументом функции (который теперь не используется) был struct inode. Но в теле функции этот inode используется:

fasync_helper( (int)inode, file, 0, &(ppci_info->async_queue1) );

Заменил (int)inode на -1, в начале функции написал lock_kernel(), перед каждым return'ом - unlock_kernel().

insmod повесил систему намертво.

Что делать?

Хм, убрал блокировку ядра - заработало. Ничего не понимаю…

Насколько это безопасно?

Решено. Точно такие же действия для USB-модуля камеры FLI помогли - все работает.

Протестировал сегодня работу PCI-7841 с микроконтроллером - все ОК.

Так что, по нагугленной мною ссылочке, немного неправильно: lock_kernel() писать не нужно (иначе модуль даже не загружается - на этапе insmod'а вешает намертво ядро).

В догонку

(может кто уже с третьим ядром работал)

Будет ли модуль с таким изменением компилироваться под третье ядро, или опять что-нибудь ковырять придется?