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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Thu, Jul 20, 2023 at 05:01:09PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 3:37 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > 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@xxxxxxxxx> 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?
> 
> I think I badly worded the previous answer. The GPIO manager has no
> notion of a user. It just receives a message from the bus. It's the
> daemon that filters the users (e.g. only users in "gpio" group can
> request and set/get GPIOs). So the answer is: one user can in fact
> request a line, it stays requested by the manager and then another
> user can set it or even release it as long as it's got the permissions
> to do so. This is similar to how sysfs works.
> 

Sure.  The point I was trying to make is how does the user determine if
they can release the line via gpio-manager?  Currently they have to walk
the requests looking for the line - and they might not find it.

This is only a minor pain point - in practice the processes will most
likely all be using gpio-manager.

> >
> > 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.
> >
> 
> This should be fine. The manager knows if it's the one controlling a
> line. It's just a matter of distinct error codes.
> 
> > > > > >
> > > > > > 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.
> >
> 
> The functionality of the DBus API doesn't have a full overlap with
> using the library. I don't see why we would want to do this. It would
> introduce a lot of overhead for no reason. I think a separate client
> that doesn't use any libgpiod APIs at all is what's needed.
> 

Fair enough. That works for me.

> > > 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?
> 
> Multiple lines, sure. Spanning multiple chips: I don't think so. Why
> would we need this?
> 

There is no need - the user can make multiple requests as they are now
persistant.  Just wondering what the API looks like to the user.

Cheers,
Kent.