Re: [PATCH 2/2] gpiolib: cdev: export the consumer's PID

[Kent Gibson]

On Tue, Sep 13, 2022 at 08:07:26PM +0300, Andy Shevchenko wrote:
> On Wed, Sep 14, 2022 at 12:17:39AM +0800, Kent Gibson wrote:
> > On Tue, Sep 13, 2022 at 05:58:32PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Sep 13, 2022 at 4:55 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> 
> ...
> 
> > > We'd need of course first expose that info like:
> > > 
> > > gpio chip:gpiochip2 lines:0,3,4,7
> > > 
> > > Does that make sense?
> > 
> > Makes sense to me, though I don't claim to know anything about fdinfo
> > field formatting.
> > 
> > e.g. I also see fdinfo fields like this:
> > 
> > eventfd-count:                0
> > eventfd-id: 1
> > 
> > so
> > 
> > gpio-chip:  gpiochip2
> > gpio-lines: 0,3,4,7
> > 
> > might be ok too.
> 
> Always think about two or more GPIO chips in the same process with 1 or more
> lines requested from each of them.
> 

I considered that - as Bart noted and as I stated earlier, each request fd
is limited to one gpiochip and one set of offsets. And those are fixed
for the lifetime of the request.
Different requests will be different fds.

But on the subject of repeats in fdinfo, I get the impression that
multi-field fdinfo rows, e.g. the tfd rows here:

pos:	0
flags:	02000002
mnt_id:	14
ino:	7661
tfd:       12 events:       19 data:                c  pos:0 ino:1ded sdev:d
tfd:       14 events:       19 data:                e  pos:0 ino:1ded sdev:d

are formatted that way as they may be repeated, so they are getting all
their ducks in a row, as it were.

So perhaps the gpio-lines could be exploded into repeated gpio-line rows?
That may be going overboard as we are only encoding one field per line
at the moment, not a struct as in the tfd case, but might we ever want
to add more details?

Again, just speculating based on the few examples I have on hand.

Cheers,
Kent.