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

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?

Cheers,
Kent.