Desenvolvimento de driver vs acesso sysfs vs mmap para GPIOs

Question

Acredito que não consegui entender completamente os benefícios de escrever drivers de dispositivos em sistemas embarcados para alguns dispositivos específicos, como GPIO, quando existem formas alternativas de fazer o mesmo trabalho.

1. Você pode acessar os GPIOs via sysfs e árvore de dispositivos.

   • Escreva uma nova sobreposição de árvore de dispositivos e ative-a
   • Vá para /sys/class/gpio
   • Exporte o pin necessário e comece a usá-lo (por meio de chamadas simples de shell ou dentro do aplicativo c/c++)

2. Escreva seu próprio driver.

   • Codifique as funcionalidades reais.
   • Exponha o driver a um nó (como /dev/tty) no espaço do usuário.
   • Escreva outro código c/c++ para acessar o driver (também pode ser acessado por meio de chamadas simples de shell)
   • Se você precisar de novas funcionalidades, primeiro altere o driver e depois o seu código. (Por que?)

3. Use diretamente /dev/mem;

   • Inclua mman.h e use o objeto /dev/mem para definir ou obter o status do GPIO.

Então,

• 1 -> ficará obsoleto e lento. (Ok, absolutamente benéfico para prototipagem rápida)
• 2 -> Como isso é mais rápido que 1? O primeiro também é outro driver GPIO, não é?
• 3 -> Não é o melhor e mais rápido caminho?

Fiz várias perguntas acima, mas aqui está a minha maior dúvida; por que não deveria ir direto para a terceira solução?

Answer 1

A vantagem da opção 2 é que você pode validar a solicitação em um único local. Digamos que, para uma máquina de lavar louça, você possa garantir que o sensor da porta diga que a porta está fechada antes de ligar a água. Claro que você pode dizer às pessoas para verificarem o status da porta antes de colocarem a água no bocal, mas será que todos farão isso?

Uma desvantagem potencial das opções 1 e 3 são as permissões. Depende de quão sofisticado é o dispositivo incorporado, mas você pode querer ter IDs de usuário diferentes fazendo coisas diferentes, por exemplo, um roteador doméstico pode ter um uid diferente executando um servidor http fazendo a UI da web e um daemon diferente operando os LEDs do painel frontal. Embora seja possível que os drivers GPIO tenham controle de acesso refinado, a maioria tem uma abordagem de tudo ou nada. Com a opção 2 você pode decidir quais usuários podem acessar quais instalações em um nível preciso.

A desvantagem da opção 2 é que ela é mais complicada e geralmente requer código no kernel.