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 11:38:19AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 11:16 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Thu, Jul 20, 2023 at 10:49:46AM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jul 20, 2023 at 10:39 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > > > On Thu, Jul 20, 2023 at 10:25:14AM +0200, Bartosz Golaszewski wrote:
> > > > > On Thu, Jul 20, 2023 at 10:05 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > > >
> > > > > > On Thu, Jul 20, 2023 at 09:59:00AM +0200, Bartosz Golaszewski wrote:
> > > > > > > On Thu, Jul 20, 2023 at 5:27 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > > > > >
> > > > > > > > On Wed, Jul 19, 2023 at 09:20:52PM +0200, Bartosz Golaszewski wrote:
> > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > > > > > > >
> > > > > > > > > While working on the DBus API, it occurred to me that while we can obtain
> > > > > > > > > the list of requested offsets from a line request, this information lacks
> > > > > > > > > context if we cannot get any information about the parent chip on which
> > > > > > > > > the request was made.
> > > > > > > > >
> > > > > > > > > We cannot reference the chip in any way as its lifetime is disconnected
> > > > > > > > > from the request but we can at least provide the path to the character
> > > > > > > > > device used to open it as a way of providing some context for the offsets.
> > > > > > > > >
> > > > > > > >
> > > > > > > > No problem with this conceptually, the only question I have is which
> > > > > > > > one of these should be stored:
> > > > > > > >  - requested path e.g. 'a_symlink_to_my_favorite_chip'
> > > > > > > >  - canonicalised path e.g. '/dev/gpiochip0'
> > > > > > > >  - chip name e.g. 'gpiochip0'
> > > > > > > >  - chip number e.g. 0
> > > > > > > >
> > > > > > > > In this patch we get the requested path, right?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, I think we should just use whatever filesystem path was used to
> > > > > > > create the chip as it would be the one allowing the caller to reopen
> > > > > > > the same chip.
> > > > > > >
> > > > > >
> > > > > > So there are instances where those four don't map to the same thing?
> > > > > >
> > > > >
> > > > > Not in a typical situation, it can happen if the chip was removed and
> > > > > another one took its place which is very unlikely.
> > > > >
> > > >
> > > > And a symlink could get changed as well.
> > > >
> > > > > I just think that we cannot have any "hard data" as in: a programmatic
> > > > > reference to the chip in the request (their lifetimes are not
> > > > > connected), so the next best thing is the filesystem path.
> > > > >
> > > >
> > > > Indeed - the chip fd used to request the line is out of scope.
> > > >
> > > > But the number of possible requested paths is many, whereas the other
> > > > three options produce a unique and comparable identifier, in a searching
> > > > sense.
> > > >
> > >
> > > So which one do you suggest?
> > >
> >
> > Any of the latter three are equivlent, so you can use whichever is most
> > convenient.  I've used canonical path in my Rust library, and chip name
> > in my Go library.  IIRC in Rust I had the canonical path handy and it
> > was easier to keep it as is than to break it down to name or number.
> > Why I went with name in the Go is lost in the mists of time.
> > I do recall toying with going with number but I wasn't sure if gpiochips
> > were guaranteed to be named 'gpiochipN'.
> >
> > Given what you have below for DBus, name looks the most natural to me.
> >
> > > > On a related point, does the DBus API allow a client to access lines
> > > > requested by another client?  And if so, how can they be sure they have
> > > > the right line?
> > > >
> > >
> > > Sure they can but various user permissions as configured in the
> > > relevant .conf file may apply.
> > >
> >
> > So setting up the dbus-daemon security policy for the objects?
> >
> 
> Not per-object unfortunately, I don't think this is possible with the
> standard dbus-daemon or dbus-broker. May be possible in the daemon
> itself if we can get the UID of the peer (we can get credentials of
> peers in pure DBus but I'm not sure if we can do it when passing
> through a bus daemon).
> 
> > > So what I've got so far in dbus (and feel free to check out the WiP[1]) is this:
> > >
> >
> > I have had a quick look at it, but so far only a quick look and I'm not
> > familiar with DBus so there is a lot of background to fill in.
> >
> > > There's an /io/gpiod1/gpiochipX object per chip implementing the
> > > io.gpiod1.Chip interface. For each line there's a separate object as
> > > well:
> > >
> > > /io/gpiod1/gpiochip0
> > > /io/gpiod1/gpiochip0/0
> > > /io/gpiod1/gpiochip0/1
> > > /io/gpiod1/gpiochip0/2
> > > /io/gpiod1/gpiochip0/3
> > >
> > > Line objects implement the io.gpiod1.Line interface and the daemon
> > > emits a PropertiesChanged signal for any status changes.
> > >
> >
> > Can the client select which of those signals it sees?
> >
> 
> They can listen for PropertiesChanged on a single line but will get an
> event on any change and will have to filter out the unwanted
> themselves.
> 
> > > You can call io.gpiod1.Chip.RequestLines() method on a chip object
> > > which will return the object path to the new request.
> > >
> > > /io/gpiod1/gpiochip0
> > > /io/gpiod1/gpiochip0/0
> > > /io/gpiod1/gpiochip0/1
> > > /io/gpiod1/gpiochip0/2
> > > /io/gpiod1/gpiochip0/3
> > > /io/gpiod1/request0
> > >
> > > The request will reference the chip object from which it was created
> > > as well as the lines it controls.
> > >
> >
> > What about the reverse mapping?
> >
> 
> As in: line-to-request? Not sure this is needed? I want the
> io.gpiod1.Line interface to expose GetValue/SetValue methods and let
> the daemon figure out the mapping logic internally. These methods
> would fail if the line is not part of any request controlled by the
> daemon.
> 

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.

And what of lines that are requested directly by apps other than the
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?


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.

Cheers,
Kent.