Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson <warthog618@gmail.com>]

On Wed, Jun 29, 2022 at 11:25:57AM +0200, Jiří Prchal wrote:
> 
> 
> On 29. 06. 22 9:23, Kent Gibson wrote:
> > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> > > Hi,
> > > using new libgpiod / chardev driver, is there any way to get state of
> > > output? I mean one process sets it for example to 1 and another process
> > > reads this output state for example to show that on web page.
> > > I have to say that old sysfs interface was more user friendly...
> > > 
> > 
> > "new" being anything since Linux 4.8 ;-)?
> > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> > provide an interface to the chip driver.  More on that later.
> > 
> > Only the process holding the line has access to the current value.
> > If you need that value elsewhere then it has to be published by that
> > process - it is not available through the GPIO API itself.
> > There is nothing preventing that process publishing the value
> > in whatever way is appropriate to your application.
> > e.g. write it to a file that can be read by your webapp, just as it
> > would from sysfs.
> > 
> > Less restrictive access models are frequently "more user friendly", but
> > have other issues. e.g. some misbehaving process just reset your
> > modem for you.
> > 
> > And sysfs has other great features like being slow and being complete
> > rubbish for events on input lines.
> > 
> > > And at second: it would be better to NOT "the state of a GPIO line
> > > controlled over the character device reverts to default when the last
> > > process referencing the file descriptor representing the device file exits."
> > > "Set and forget" behavior is more natural to what some gpios are used. For
> > > example resetting external modems, need set 1 for short time, then to 0 and
> > > leave it for long long time until next reset is needed. It's non sense to
> > > keep running some process only to keep output at 0.
> > 
> > Agreed, that might be more natural, but that behaviour is not by choice,
> > it is a consequence of the kernel internals.  In short, if the GPIO
> > subsystem does not hold the chip then the driver is free to do what it
> > likes to it.
> > So when you release a line all bets are off.
> > It may stay where you left it, but it may not - it may even switch to an
> > input - it depends on the driver.
> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?
> 

If you hold a line then it is guaranteed to remain in the state you
request. Changing or releasing other lines will not alter that line.

If you release a line then other processes are free to request it and
alter it.  But if no other process request it, it will generally will
remain in the state you left it.  Generally.
The exception is if you release the last requested line on the chip, in
which case the GPIO subsystem will release the chip to the driver and
what happens to all the lines on the chip after that is up to the driver.

The big problem is you never know if the line you are releasing is the
last requested line.  Unless you explicitly hold at least one line.

> > If it works for you that's great, but without major kernel changes
> > libgpiod has no better option than to provide the caveat as the "set and
> > forget" behaviour is something that it cannot guarantee.
> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
> when the proces dies systemd will start it again
> 

No, you don't have to emulate sysfs, you can do whatever works for you,
that was just an example.

The libgpiod tools are not the only interface libgpiod provides - they
are just the command line/shell interface.
You would not call gpioset repeatedly, you would request the line using
libgpiod (for C), or the appropriate bindings for the language you are
working in, and then set the line as required in your program.

If you are working in shell with libgpiod v1.6.3 then there is no way
to hold a line and subsequently change it.  You would have to repeatedly
call gpioset and hope for the best in between times.
For libgpiod v2 I'm working on an interactive mode for gpioset that
keeps it running and holding the line(s) and you pipe set commands to it
from your script as required.

If you need anything more complicated for scripting then the Python
bindings would be the way to go.

> and another scenario:
> proces checks time, if is the right time -> gpioset =1
> other proces reads output and print out on web
> 

line manager process:
request line (using appropriate binding)
wait until whenever
set=1 (using appropriate binding)
publish line state where web server can see
...

web server process:
webserver asked for state
returns last published value

Cheers,
Kent.