User space tools

User space tools

[Leszek Dubiel]

Different bash scripts from different servers
ssh to Raspberry PI and change GPIO line:

              /dev/gpiochip2, pin number 7.

like this:

    gpioset -b -msignal /dev/gpiochip2 7=1



If another script does for example:

     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



Is there a better way to kill o replace
previous instance of running gpioset?

Or is it going to be better in new version v2 of user space tools?

Elegant way to kill previous gpioset?

[Leszek Dubiel]

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?

Re: Elegant way to kill previous gpioset?

[Kent Gibson]

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@gmail.com/
[2] https://lore.kernel.org/linux-gpio/20221114040102.66031-4-warthog618@gmail.com/
[3] https://lore.kernel.org/linux-gpio/Yyw5mivLAgWZIx0W@sol/T/

Re: Elegant way to kill previous gpioset?

[Leszek Dubiel]

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

Re: Elegant way to kill previous gpioset?

[Kent Gibson]

On Wed, Nov 16, 2022 at 09:54:21AM +0100, Leszek Dubiel wrote:
> 
> 
> 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
> 
> 

Understand that GPIOs are a managed resource, like files, and what
you are asking for here is equivalent to a function that would kill
whatever process has a file open whenever you write to that file.
So, no there isn't.

It is really unfortunate that killing the process holding the line is the
only viable approach when using the libgpiod tools at the moment, but
better solutions to your problem should be available soon.
Alternatively you can use, say, the Python bindings to write something
that better suits your particular needs.

Cheers.
Kent.