Действительно ли возможно назвать функцию обратного вызова пространства пользователя от пространства ядра в Linux (ioctl)?
Действительно ли возможно развернуть интерфейс ioctl в Linux так, чтобы приложение пространства пользователя могло отправить указатель на функцию к драйверу пространства ядра?
Я в особенности думаю о способах обработать поток управляемым пользователем способом, но делаю его в ядре. Те операции могли быть присоединены к модулю ядра, но это сделает разработку намного легче, поскольку я не должен был бы смешивать с ядром во время разработки.
Строго говоря, это было бы процессом:
- Данные считаны драйвером в буфер.
- Данные обрабатываются этими пользовательскими функциями на месте.
- Еще некоторая обработка сделана, возможно с некоторыми блоками HW.
- Данные используются приложением пространства пользователя.
3 ответа
Я думаю, вы можете добиться того, чего хотите, если ваш драйвер предоставит одно или несколько символьных устройств (или блочных устройств), которые открываются вашими приложениями пользовательского пространства.
Затем вы можете использовать inotify ( статья в журнале Linux ) для обмена данными между ядром и пользовательским пространством. Ioctl или запись на устройство для взаимодействия с пользовательским пространством -> ядром. Обмен данными также может осуществляться путем чтения / записи в один или несколько файлов устройства.
В качестве альтернативы вы можете предоставить записи файловой системы / proc или / sys или использовать netlink.
Вы также можете рассмотреть ksocket :
Ksocket - это модуль ядра Linux 2.6 , который предоставляет интерфейсы сокетов в стиле bsd (а именно socket, bind, {{ 1}} слушать, подключаться, принимать, ...) для разработчиков ядра, чтобы облегчить их сетевое программирование в пространстве ядра Linux. Интерфейсы, представленные ksocket, во многом совпадают с их эквивалентами в glibc, поэтому даже новые разработчики пространства ядра не будут иметь препятствий в разработке сети ядра. связанные программы.
Я думаю, вы просите квадратный круг: если бы ядро просто выполняло вашу функцию "пользовательского пространства" напрямую, это не было бы "пользовательское пространство" "а скорее доморощенная система загружаемых модулей. Я предполагаю, что то, что вы на самом деле хотите, - это способ выяснить, что делать, чтобы все это работало без сбоев вашего ПК каждый раз, когда вы делаете ошибку. Может быть, вы могли бы использовать обработчики сигналов как средство «обратного вызова», но я слишком ржав, чтобы указать, как вы могли бы вернуть ядру, как если бы возвращением вызова функции. Проблема здесь в том, что при любом переключении контекста «пользовательская среда -> ядро» ядро запускается со свежим стеком, поэтому обратного адреса давно нет. Как насчет того, если вы объедините обработчик сигналов с mmap'ing / dev / mem и позволите псевдодрайверу пользовательского пространства напрямую выталкивать структуры данных драйвера режима ядра? Но затем вы снова перезагружаетесь, когда делаете ошибку, если вы не понимаете, как сделать mmap только структурами данных вашего драйвера? Другими перепрофилируемыми механизмами могут быть линейные дисциплины STREAMS и TTY; Я думаю, что это дает некую способность к трансмогрификации. Конечно, все это не является хорошей идеей в качестве постоянного решения!
В вашем варианте использования постоянно упоминаются данные.
Возможно, вы хотите разделить память между ядром и пользовательским процессом. Вы могли помещать данные и / или команды в общую память, а код процесса / ядра на другой стороне мог читать их и делать что угодно. Вызов get_user_pages_fast () может сделать память процесса доступной для ядра, даже если процесс в данный момент не запущен.