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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

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.

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

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

>
> > $ # List available requests
> > $ gpiocli requests
> > request0 (gpiochip0) offsets: [4]
>
> But that will only return the requests made by gpio-manager, right?

Yes.

Bart

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