Как пользовательский процесс может получить доступ к символьному устройству, загруженному моим модулем - PullRequest
Новая
       31

Как пользовательский процесс может получить доступ к символьному устройству, загруженному моим модулем

1 голос
/ 05 октября 2011

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

Я знаю, что единственный способ сделать это - загрузить модуль.Чтобы позволить пользователю общаться с ним, мне сказали использовать символьное устройство (которое должно быть в / dev /, верно?).Я загрузил один успешно.Моя проблема в том, что я не знаю, как пользовательский процесс обращается к нему без системного вызова.(мне сказали использовать ioctl) Может кто-нибудь показать, как пользовательский процесс может вызывать ioctl, например, который был загружен моим модулем?

Спасибо, Shai

1 Ответ

0 голосов
/ 05 октября 2011

Для ответа ниже я предположил, что вы разрабатываете модуль Linux. Перечитав ваш вопрос, я понял, что мог неправильно истолковать проблему.

Существует несколько механизмов взаимодействия с драйвером ядра:

  • a /proc запись (она же procfs )
  • ioctl через интерфейс устройства
  • напрямую через интерфейс устройства

Наиболее распространенным методом является последний, который использует системные вызовы read() и / или write(), чтобы вызвать действие драйвера. Хотя эти системные вызовы обычно передают чистые данные, ничто не мешает конкретному драйверу вместо передачи метаданных через интерфейс ввода-вывода.

С другой стороны, если драйвер уже имеет полезную дисциплину чистых данных, для которой read() и write() не подходят для метаданных, то системный вызов ioctl() является своего рода универсальным швейцарским армейским ножом для делать все, что связано с файлом, например, загружать или выгружать магнитную ленту, извлекать DVD-диск, находить адрес Ethernet сетевой карты или выяснять, сколько ошибок произошло на диске. Было определено так много кодов операций ioctl , что вы, вероятно, сможете найти подходящий для повторного использования. Большой недостаток интерфейса ioctl заключается в том, что он лучше всего подходит для использования пользовательской программой, поэтому было бы неудобно или трудно передавать данные через ioctl, подключенный к конвейеру стандартных программ.

Интерфейс /proc сочетает в себе лучшее из двух предыдущих приемов: он допускает использование соглашений stdin / stdout со стандартными служебными программами, но также предоставляет интерфейс для драйвера устройства, который не зависит от каких-либо ввод / вывод через механизм штатного драйвера. Например, попробуйте cat /proc/net/tcp в вашей системе Linux. Показывает состояние всех TCP соединений.

Хорошая статья о реализации функции procfs : create_proc_entry(). Реализация ioctl хорошо освещена здесь . Подход метаданных так же легко закодировать, как и любой другой драйвер устройства, хотя он может представлять концептуальные препятствия для опытного разработчика.

...