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

> 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 what I've got so far in dbus (and feel free to check out the WiP[1]) is this:

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.

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.

Bart

> Cheers,
> Kent.

[1] https://github.com/brgl/libgpiod-private/tree/topic/dbus/