Модуль ядра или приложение пользовательского пространства
У меня дилемма. Я не знаю, каков наилучший подход к следующему сценарию, а затем, если есть смысл тратить время на разработку модуля ядра.
У меня есть аппаратное обеспечение (FPGA), которое выставлено, как и многие модули (около 30). Каждый модуль может быть определен как:
- Базовый адрес модуля;
- Смещение полей (от базового адреса);
- Максимальное количество полей на модули составляет около 10;
- Каждое поле имеет свой собственный тип, такой как uint32_t, float32_t, uint32_t [] и т. Д .;
- Некоторые поля только для чтения / записи, а другие только для чтения;
- Обычно модуль готов как есть. Я имею в виду, что нет необходимости реализовывать какую-либо логику для проверки возможности записи в поле (кроме нескольких случаев).
На целевом устройстве есть пользовательский дистрибутив Linux (созданный из Yocto).
Что ты думаешь лучше?
-
Приложение в пространстве пользователя, которое использует mmap (/ dev / mem для отображения всех
модули), а затем читает / пишет непосредственно из / в память. У меня есть C ++
реализация и это работает, но, возможно, это не самый лучший
Решение … Мне нужно вручную установить все смещения, используя много
reinterpret_cast<> правильно читать данные и если что-то есть
неправильно вылетает приложение; -
Реализовать символьное устройство
драйвер для предоставления каждого модуля, например / dev / module1, / dev / module2 и т. д.?
и использовать в пространстве пользователя open / write / read / release / ioctl. я просто
начал читать огромное руководство по разработке ядра Linux, и я
Я не уверен, если устройство персонажа хорошая идея, особенно
как выставить так много модулей с таким количеством полей в пользовательское пространство; - Другой.
Большое спасибо за любые идеи.
Решение
С помощью /dev/mem это довольно просто, однако это также вызывает некоторые серьезные проблемы с безопасностью. Вы должны либо запустить приложение от имени пользователя root, либо сделать /dev/mem файл доступен для других пользователей, которые оба нежелательны в проектах, которые в какой-то момент станут продуктами. Если вредоносный процесс может получить доступ к /dev/mem файл может получить доступ к любому секрету, хранящемуся в оперативной памяти, или повредить любое приложение, включая само ядро. Даже если ваше приложение является единственным, способным получить доступ к этому файлу, любая проблема безопасности вашего кода становится проблемой безопасности всей системы.
Подготовка драйвера, очевидно, не простая задача, но она позволяет вам отделить (обычно простой) привилегированный код от приложений в пространстве пользователя. В простейшем случае вам нужно только предоставить некоторые методы чтения и записи в регистр (через ioctl). Они должны проверить, правильно ли выровнен адрес и ограничен ли он адресным пространством устройства. Кроме того, драйвер обычно выполняет любую дополнительную трансляцию адресов, поэтому клиентскому приложению не нужно знать, под какой физический адрес было сопоставлено ваше устройство (как, например, в случае PCI Express).
Я бы не советовал писать драйвер с нуля, а переназначить существующий код. В упомянутом случае PCI Express я использовал два источника вдохновения — драйвер Xilinx, описанный здесь: https://www.xilinx.com/support/answers/65444.html (включая источники) и более сложные ‘pcieuni’ и ‘gpcieuni’ из проекта ChimeraTk (https://github.com/ChimeraTK).
Другие решения
Других решений пока нет …