Re: Elegant way to kill previous gpioset?

[Leszek Dubiel <leszek@dubiel.pl>]

 > 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.

Yes, that's true.



 > 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

I have tried pipe even in current gpioset tools, because if I
hit Enter then it gpioset exits. Similar as last line above.

Thanks to your explanation I know what's the
intention behind "--interactive" option.





 > Would that work for you?

I was wondering if there is some "one-liner" that
recofigures pin, something like:

                 gpioset -b -msignal --autokill /dev/gpiochip2 7=0

or
                 gpioset -b -msignal --force /dev/gpiochip2 7=0

that does these two commands at once:

               pkill -ef "^gpioset .* /dev/gpiochip2 7=[01]$"
               gpioset -b -msignal /dev/gpiochip2 7=0



New tools with "setpipe" and "--interactive" would
do the job too. :) :)






 > 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.


Thank you for detailed explanation.