Разработка драйверов против доступа к sysfs против mmap для GPIO

Question

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

1. Доступ к GPIO можно получить через sysfs и дерево устройств.

   • Напишите новое наложение дерева устройств и включите его
   • Перейдите в /sys/class/gpio
   • Экспортируйте нужный пин и начните его использовать (через простые вызовы оболочки или внутри приложения C/C++)

2. Напишите свой собственный драйвер.

   • Закодируйте реальные функции.
   • Откройте доступ к драйверу на узле (например, /dev/tty) в пространстве пользователя.
   • Напишите еще один код на C/C++ для доступа к драйверу (к нему также можно получить доступ с помощью простых вызовов оболочки)
   • Если вам нужны какие-либо новые функции, сначала измените драйвер, а затем свой код. (Зачем?)

3. Использовать напрямую /dev/mem;

   • Включите mman.h и используйте объект /dev/mem для установки или получения статуса GPIO.

Так,

• 1 -> будет устаревшим и медленным. (Ладно, безусловно полезно для быстрого прототипирования)
• 2 -> Чем он быстрее 1? 1-й — это тоже еще один драйвер GPIO, не так ли?
• 3 -> Разве это не лучший и самый быстрый способ?

Я задал несколько вопросов выше, но вот мой самый главный вопрос: почему бы мне сразу не воспользоваться третьим решением?

Answer 1

Преимущество варианта 2 в том, что вы можете проверить запрос в одном месте. Например, для посудомоечной машины вы можете убедиться, что датчик двери сообщает, что дверь закрыта, прежде чем вы включите воду. Конечно, вы можете сказать людям проверить состояние двери, прежде чем они включат воду, но будут ли они все это делать?

Потенциальным недостатком вариантов 1 и 3 являются разрешения. Это зависит от сложности встроенного устройства, но вы можете захотеть иметь разные идентификаторы пользователей, выполняющие разные функции, например, домашний маршрутизатор может иметь другой идентификатор пользователя, запускающий http-сервер, выполняющий веб-пользовательский интерфейс, и другой демон, управляющий светодиодами на передней панели. Хотя драйверы gpio могут иметь детальный контроль доступа, большинство из них имеют подход «все или ничего». С вариантом 2 вы можете решить, какие пользователи могут получить доступ к каким объектам на детальном уровне.

Недостатком варианта 2 является то, что он более сложен и обычно требует кода в ядре.