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

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.

Bart