Linux: problema de sincronización de exportación de gpio

Creado en 27 mar. 2014 · 9Comentarios · Fuente: raspberrypi/linux

Si los siguientes tres comandos se ejecutan individualmente desde la línea de comandos en la Raspberry Pi usando Raspbian (2014-01-07-wheezy-raspbian.zip), entonces se ejecutan correctamente:

pi<strong i="6">@raspberrypi</strong> ~ $ echo 23 > /sys/class/gpio/unexport
pi<strong i="7">@raspberrypi</strong> ~ $ echo 23 > /sys/class/gpio/export
pi<strong i="8">@raspberrypi</strong> ~ $ echo out > /sys/class/gpio/gpio23/direction 
pi<strong i="9">@raspberrypi</strong> ~ $

Sin embargo, si se ejecutan juntos en la misma línea, hay un error de permiso denegado:

pi<strong i="13">@raspberrypi</strong> ~ $ echo 23 > /sys/class/gpio/unexport; echo 23 > /sys/class/gpio/export; echo out > /sys/class/gpio/gpio23/direction
-bash: /sys/class/gpio/gpio23/direction: Permission denied
pi<strong i="14">@raspberrypi</strong> ~ $

El error de permiso denegado se produce porque "echo out> / sys / class / gpio / gpio23 / direction" se está ejecutando antes de que los bits de grupo y permiso para "/ sys / class / gpio / gpio23 / direction" se hayan establecido en los valores adecuados. . Los bits de grupo y permiso son "root" y "-rw-r - r--", pero deberían ser "gpio" y "-rwxrwx ---".

Este problema de tiempo se puede ver en la secuencia de comandos a continuación, que exporta gpio 23 y enumera el contenido de "/ sys / class / gpio / gpio23 /" dos veces. La salida del primer comando ls es bastante diferente a la salida del segundo comando ls. Tanto el grupo como los permisos de todos los archivos han cambiado.

pi<strong i="19">@raspberrypi</strong> ~ $ echo 23 > /sys/class/gpio/unexport; echo 23 > /sys/class/gpio/export; ls -l /sys/class/gpio/gpio23/; ls -l /sys/class/gpio/gpio23/
total 0
-rw-r--r-- 1 root root 4096 Mar 27 21:51 active_low
-rw-r--r-- 1 root root 4096 Mar 27 21:51 direction
-rw-r--r-- 1 root root 4096 Mar 27 21:51 edge
drwxr-xr-x 2 root root    0 Mar 27 21:51 power
lrwxrwxrwx 1 root root    0 Mar 27 21:51 subsystem -> ../../../../class/gpio
-rw-r--r-- 1 root root 4096 Mar 27 21:51 uevent
-rw-r--r-- 1 root root 4096 Mar 27 21:51 value
total 0
-rwxrwx--- 1 root gpio 4096 Mar 27 21:51 active_low
-rwxrwx--- 1 root gpio 4096 Mar 27 21:51 direction
-rwxrwx--- 1 root gpio 4096 Mar 27 21:51 edge
drwxrwx--- 2 root gpio    0 Mar 27 21:51 power
lrwxrwxrwx 1 root gpio    0 Mar 27 21:51 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Mar 27 21:51 uevent
-rwxrwx--- 1 root gpio 4096 Mar 27 21:51 value

¿Es este un problema que debe abordarse?

Fuente

fivdi

Comentario más útil

Este es un problema muy molesto que requiere desagradables soluciones. No debería haber estado cerrado.

karolba en 27 ago. 2016

👍2

Todos 9 comentarios

Acabo de editar la publicación anterior. Inicialmente, ninguna de las apariciones de "echo 23> / sys / class / gpio / inexport" estaba allí. La no exportación solo es necesaria para que el gpio vuelva a su estado inicial no exportado.

fivdi en 28 mar. 2014

Yo obtengo:

pi<strong i="6">@raspberrypi</strong>:~ $ ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 Mar 27 17:41 export
lrwxrwxrwx 1 root root    0 Mar 27 17:41 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
--w------- 1 root root 4096 Mar 27 17:41 unexport
pi<strong i="7">@raspberrypi</strong>:~ $ echo 23 > /sys/class/gpio/unexport
-bash: /sys/class/gpio/unexport: Permission denied

que es lo que esperaba. Solo root tiene permiso para acceder a / sys / class / gpio / inexport, por lo que cuando pi intenta hacer esto, se le niega el permiso correctamente.

Si ejecuto "sudo su" primero, el comando funciona como se esperaba.

popcornmix en 28 mar. 2014

Eso es lo que solía obtener en versiones anteriores o Raspbian, pero en 2014-01-07-wheezy-raspbian obtengo:

pi<strong i="7">@raspberrypi</strong> ~ $ ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Mar 28 16:58 export
lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Mar 28 17:01 unexport
pi<strong i="8">@raspberrypi</strong> ~ $ echo 23 > /sys/class/gpio/export 
pi<strong i="9">@raspberrypi</strong> ~ $

Todo funciona bien y no hay errores. Todos los miembros del grupo gpio tienen permiso para acceder a / sys / class / gpio / export y pi es miembro del grupo gpio.

pi<strong i="13">@raspberrypi</strong> ~ $ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users netdev input spi gpio

uname genera lo siguiente:

pi<strong i="17">@raspberrypi</strong> ~ $ uname -a
Linux raspberrypi 3.10.34+ #661 PREEMPT Thu Mar 27 00:36:02 GMT 2014 armv6l GNU/Linux

fivdi en 28 mar. 2014

El comportamiento cambió ya que usamos algunas cosas de udev de la gente de piface. Tiene razón en que debe esperar a que udev cambie los permisos en el dispositivo creado. Esto es algo del espacio de usuario, así que no es realmente para este repositorio, pero no estoy seguro de que haya una manera de mejorarlo.

asb en 28 mar. 2014

¿Esto funciona?

echo 23 > /sys/class/gpio/unexport; echo 23 > /sys/class/gpio/export; sleep 1; echo out > /sys/class/gpio/gpio23/direction

popcornmix en 28 mar. 2014

@asb Ok, gracias por la información. Creo que cambiaré el código en onoff para que espere a que cambien los permisos. La ventaja es que las aplicaciones que utilizan onoff pueden evitar problemas de superusuario.

@popcornmix sí, eso funciona, gracias.

fivdi en 28 mar. 2014

Puedo ver el valor en la extensión del proceso de permisos GPIO en el espacio del usuario, pero esta implementación
ha dañado la semántica de la operación de exportación GPIO del kernel. La escritura en / sys / class / gpio / export
debe esperar a que el proceso de espacio de usuario informe que ha completado su trabajo antes de que vuelva la escritura.

Soluciones alternativas que dicen que los usuarios deben esperar algún tiempo para que los metadatos del sysfs se establezcan después de una
Las operaciones de exportación son muy feas porque no hay un período correcto de espera. Estrategia alternativa que
busca cambios en los metadatos (por ejemplo, grupo establecido en gpio) son inadecuados porque el propósito de la
El proceso de permiso de espacio de usuario es flexibilidad: podría decidir que la raíz es el grupo adecuado y no hay cambios.
ocurre.

El cambio semántico a la operación de exportación GPIO del kernel es un obstáculo para el código portátil, no solo
entre Raspberry Pi y otras plataformas de hardware, pero también entre diferentes Linux
distribuciones en Raspberry Pi.

ryniker en 9 nov. 2014

Acordado. Es responsabilidad del kernel proporcionar una implementación de sysfs que funcione, y la implementación de Raspbian está claramente rota de una manera fea. No veo cómo se puede haber marcado este problema como cerrado.