Re: [libgpiod][PATCH 0/5] core: provide information about the parent chip in line requests

[Kent Gibson <warthog618@gmail.com>]

On Thu, Jul 20, 2023 at 02:30:45PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 11:52 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> >
> > The case I was thinking of was wanting to release a line, and if you
> > don't know which request you will have to walk the request objects.
> >
> 
> You cannot release a single line if it's part of a wider request though.
> 

Of course. Unless we were to extend the uAPI to allow that.

> > And what of lines that are requested directly by apps other than the
> > gpio-manager?
> >
> 
> You can tell they're used but cannot request them just like with any
> other user of the cdev.
> 

This is going to be a pain point - the concept of "used" is getting
muddy.

Say two processes want to get a line.
So both need to request it before they can get it?
Or only one does the request and both can get?

The latter case is painful to use.
The former requires request being idempotent or at least to return an
error that distiguishes a line already held by gpio-manager and a line
already held but not by gpio-manager.

> > > >
> > > > Where do edge events fit in there?
> > > >
> > >
> > > It's a signal exposed by the io.gpiod1.Line interface.
> >
> > But separate from the PropertiesChanged?
> >
> 
> Yes. PropertiesChanged is emitted on changes in properties (direction,
> edge, all reported by gpionotify) while EdgeEvent is for edges
> exclusively.
> 
> >
> > I am also wondering if the tools can be extended with the option to
> > perform their ops using the gpio-manager, particularly get/set/mon that
> > currently require exclusive access.
> >
> 
> There's a client app already functional in my WiP branch. Think nmcli
> for NetworkManager. It doesn't link against libgpiod - only uses the
> DBus API.
> 

Sure - doesn't mean other tools can't use the DBus API too.
My thinking was existing users of GPIO tools could just add
an option, say -D, to their scripts to switch over to gpio-manager.

> You can do something like this (not all of this is implemented yet):
> 
> $ # Wait for a chip with a particular label to appear
> $ gpiocli wait --chip="foobar" --timeout=10s
> $ # Request a line for edge events
> $ gpiocli request --input --rising-edge --falling-edge foo
> request0

Will that support multiple lines, possibly spanning multiple chips?

> $ # List available requests
> $ gpiocli requests
> request0 (gpiochip0) offsets: [4]

But that will only return the requests made by gpio-manager, right?

> $ # Wait for edge events:
> $ gpiocli monitor foo
> Offset: 4 RISING EDGE Timestamp: 3425234234
> $ # Release the request
> $ gpiocli release request0
> 
> This way the user can easily use bash scripts, command line or even
> any DBus library out there while we still use the character device in
> the daemon and ditch sysfs.
> 

Agreed.  As covered earlier, access control needs to be fleshed out, but
other than that I don't see any obvious deal breakers.

Cheers,
Kent.