Re: Elegant way to kill previous gpioset?

[Kent Gibson <warthog618@xxxxxxxxx>]

On Tue, Nov 15, 2022 at 09:36:59PM +0100, Leszek Dubiel wrote:
> 
> 
> 
> Different bash scripts from different servers
> ssh to Raspberry and set GPIO line:
> 
>         /dev/gpiochip2, pin number 7.
> 
> with such command:
> 
>         gpioset -b -msignal /dev/gpiochip2 7=1
> 
> 
> 
> If another script tries:
> 
>       gpioset -b -msignal /dev/gpiochip2 7=0
> 
> then it gets:
> 
>       gpioset: error setting the GPIO line values: Device or resource busy
> 
> 
> 
> So every bash script kills previous instance
> before setting gpio line:
> 
>      pkill -ef "^gpioset .* /dev/gpiochip2 7=[01]$"
>      gpioset -b -msignal /dev/gpiochip2 7=0
> 
> 
> 
> Pkill is bad solution:
> 
> 1. it is very slow, because it has to grep full command lines.
> 
> 2. it doesn't work if one of bash scripts
> used little bit different command, for example:
> 
>      gpioset -b -msignal /dev/gpiochip2 7=0 5=2
>      gpiomon             /dev/gpiochip2 7
> 
> 
> 
> Is there a better way to kill o replace
> previous instance of running gpioset?
> 

The best way is not to have to kill it.
If you kill the gpioset then the state of the line becomes indeterminate
so you are open to glitches as well as some other process grabbing the
line.

To address this the gpioset for v2[1] has an interactive mode that allows
you to pipe commands to it.  The tests for v2[2] (gpio-tools-tests.bats)
demonstrate that by launching the gpioset from bash using coproc and then
driving the gpioset via the pipe to the co-process.
For a more long lived solution you can setup a named pipe and then write
commands to that to update the line:

mkfifo setpipe
gpioset --interactive -c gpiochip2 7=0 < setpipe &
echo "set 7=1" > setpipe
or
echo "toggle" > setpipe

You can even kill it with:

echo "exit" > setpipe

Would that work for you?

Personally, for situations like this I don't use the tools, I use one of
the bindings to write a daemon that controls the line and receives its
commands from some other source.

There are plans for a generic daemon that would allow you to access lines
via dbus, but that hasn't got past the planning stages AFAIAA.

Wrt identifying and killing processes holding particular lines,
the ability to identify the GPIO lines held by processes via the /proc
filesystem has recently been added to the 6.1 kernel[3].  There are
plans for a tool that will use that to return the PID holding a line,
but again that is still in the planning stages.

Cheers,
Kent.

[1] https://lore.kernel.org/linux-gpio/20221114040102.66031-3-warthog618@xxxxxxxxx/
[2] https://lore.kernel.org/linux-gpio/20221114040102.66031-4-warthog618@xxxxxxxxx/
[3] https://lore.kernel.org/linux-gpio/Yyw5mivLAgWZIx0W@sol/T/