Прошу помощи в такой проблеме, потому как запнулся и не могу ничего придумать.
Есть некий модуль, работающий в ядре, есть некое приложение в userspace.
Для того, чтобы работать с модулем из userspace, создал несколько системных вызовов дополнительных, именно через них будут передаваться данные в модуль и выполняться управление оным.
И вот после создания sys_call запнулся на том, что код функции-обработчика вызова должен быть статически внесен в код ядра и не может быть скомпилирован в качестве модуля, выдает ошибку при линковке. А это не выход, так как при любом изменении необходимо будет пересобирать ядро

В общем вопрос в том как с помощью системного вызова можно организовать взаимодействие модуля ядра и подсистемы пользователя. Ну или как из функции-обработчика системного вызова передать данные в модуль.

для того, чтобы организовать взаимодействие, абсолютно не надо писАть свой системный вызов
для этого есть procfs, sysfs, char устройства, netlink

про procfs, sysfs, пайпы и сокеты знаю, однако хотелось бы познакомиться с реализацией системных вызовов для модулей ядра. Или каким образом из ядра можно вызвать функцию, находящуюся в модуле ?

И, кстати, если необходимо предавать большой объём данных модулю, то какой из способов взаимодействия будет лучше?

модуль - это тоже ядро
если функция определена в *.c модуле, который впоследствие станет модулем ядра, то образ ядра не будет собран, т. к. адреса всеъ символов должны быть к этому моменту известны



char устройство и mmap

Решил попробовать проделать эту операцию через сокеты netlink вроде как и удобно и то что надо именно мне, однако наткнулся на очередной косяк - в определённых моментах ядро зависает и я не могу выяснить из-за чего



в логах



Зависание чаще всего происходит после выгрузки модуля, но не сразу, а через некоторое время, когда, например, пытаюсь запустить MC
Также был замечан случай когда зависало после ответа пользователю : knetlink_process: reply nlmsg len 1040 type 2 pid 5772.

rector, 
зачем вы в knetlink_exit в kfree_skb передаете struct sock*?
kfree_skb освобождает пакет (aka struct sk_buff*)

Хм...возможно тут таки вышел прогон.
В первоначальном варианте в knetlink_exit вместо kfree_skb было sock_release( knetlink_sk->sk_socket ); однако это особо ничего не меняет, ошибка может возникнуть как до выхода из модуля так и после. Возможно что то с указателями, но я в упор не вижу что именно может вызвать зависание, данные передаются нормально как в ядро так и из него.

все-таки если в вместо kfree_skb написать netlink_kernel_release(knetlink_sk)
ошибка есть?

ничего не поменялось, все та же ошибка + при обращении к сетевой подсистеме - например dhclirnt eth0 хочу сделать ядро опять орёт, пишет что ifconfig tained G и т.д.