Можно ли вызвать функцию обратного вызова пользовательского пространства из пространства ядра в Linux (ioctl)?

можно ли расширить интерфейс ioctl в Linux, чтобы пользовательское приложение могло отправить указатель на функцию драйверу пространства ядра?

Я, в частности, думаю о способах обработки потока управляемым пользователем способом, но делаю это в ядре. Эти операции могут быть подключены к модулю ядра, но это сделает разработку намного проще, так как мне не нужно будет возиться с ядром во время разработки.

более конкретно, это был бы процесс:

  1. данные считываются драйвером в буфер.
  2. данные обрабатываются этими пользовательскими функциями на месте.
  3. выполняется дополнительная обработка, возможно, с некоторыми блоками HW.
  4. данные используются приложением пользовательского пространства.
7
ioctl kernel linux-device-driver linux-kernel

3 ответов

Я думаю, вы можете достичь того, что хотите, если ваш драйвер предоставит одно или несколько символьных устройств (или устройств блокировки), которые откроют ваши пользовательские космические приложения.

тогда вы можете использовать inotify (linux journal article) для ядра - > связь событий пользовательского пространства. Ioctl или запись на устройство для пользовательского пространства - >связь событий ядра. Обмен данными также может быть достигнут путем чтения / записи на одно или несколько устройств файлы.

в качестве альтернативы вы можете предоставить /proc или /sys записи файловой системы или использовать netlink.

вы также можете рассмотреть ksocket:

Ksocket-это модуль ядра linux 2.6 это обеспечивает гнездо BSD-типа интерфейсы (а именно сокет, bind, слушайте, подключайтесь, принимайте ...) для разработчики ядра, чтобы облегчить их сетевой прогарамминг в ядре linux пространство. Интерфейсы ksocket представляют почти такие же, как их аналог в glibc, поэтому даже новые разработчики для пространство ядра не будет иметь барьера в развитие сетевого ядра программы.

7

Я думаю, вы просите квадратный круг: если бы ядро просто выполняло вашу функцию "userland" напрямую, это была бы не "userland", а скорее домашняя загружаемая модульная система. Я предполагаю, что вы действительно want-это способ выяснить, что делать, чтобы все это работало без сбоев вашего ПК каждый раз, когда вы делаете ошибку. Возможно, вы могли бы злоупотреблять обработчиками сигналов как средством "обратного вызова", но я слишком ржавый, чтобы указать, как вы получите назад к ядро как бы по функции call return. Проблема здесь в том, что в любом переключателе контекста userland->kernel ядро начинается с нового стека, поэтому обратный адрес давно исчез. Как насчет того, если вы объедините обработчик сигналов с mmap'ING /dev/mem и позволите псевдодрайверу userland напрямую тыкать структуры данных драйвера режима ядра? Но затем вы возвращаетесь к перезагрузке, когда делаете ошибку, если вы не выясните, как mmap только структуры данных вашего водителя? Другой механизмы repurposeable могут быть потоки и tty линии дисциплинам; я думаю, что они придают какой-то трансмутирую способности. Конечно, ничто из этого не является хорошей идеей в качестве постоянного решения!

4

ваш прецедент продолжает упоминать данные.

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

2