Re: Some thoughts following a brief test of libgpiod ver 2.1

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, Jan 03, 2024 at 04:09:01PM -0600, Seamus de Mora wrote:
> On Wed, Jan 3, 2024 at 12:35 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > On Wed, Jan 3, 2024 at 6:53 PM Seamus de Mora <seamusdemora@xxxxxxxxx> wrote:
> > >
> > > On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@xxxxxxxxx> wrote:
> > > > >
> > > >
>         [ snip ]
> > > >
> > > I thought this issue of line ownership had been resolved...  i.e. the
> > > system driver would take control of the line once the user's process
> > > had exited? Maybe I'm confused on this point, but I *thought* I had
> > > read that somewhere else?
> >
> > The driver is just a low-level interface between the core GPIO code
> > and the hardware. It does not typically take control of any GPIOs
> > (unless it calls gpiochip_request_own_desc() but that's an internal
> > detail).
> >
>
> OK - that *sounds* like a different story than the one your partner is
> telling... do you guys ever "talk"?
>

Formerly, once the user releases the line it becomes unowned.  That is
certainly true from the userspace perspective.  My interpretation is
that when a user releases the request the line ownership reverts to the
driver, cos in reality that is now in control of the line.

Sure we talk, but we can also have differing points of view.
You clearly have no problems talking, and I still take issue with
your tone.  Where is that damn hatchet?

> > >
> > > Nevertheless, to address your questions: No - I didn't mean to infer
> > > that there's only one user. I understand that you (library developer)
> > > need to account for different users. But GPIO control is not a unique
> > > issue in Linux (or any multi-user OS). It is the same if we were
> > > talking about control of a serial port/UART... how is that arbitrated
> > > between users?
> >
> > It's exactly the same. The first user to claim a serial port (be it an
> > in-kernel serdev or a user opening /dev/ttyX) takes exclusive usage
> > and keeps the port until it releases it.
> >
>
> OK - we agree on that much.
>
> > >
> > > WRT a GPIO line, I'd say "the user" is the one who issued the gpioset
> > > command. In the context of your example ("When gpioset acquires the
> > > GPIO for exclusive usage"), why could gpioset (or the user who issued
> > > the gpioset command) not 'make a claim for exclusive usage' of the
> > > GPIO line? If other users/processes subsequently attempted to claim
> > > the same line, their claim would simply be disallowed - unless they
> > > were `root`. Is there a reason why this model of ownership could not
> > > work?
> >
> > This is precisely what happens though (except for root being able to
> > override a regular user)? Or am I not understanding this paragraph?
> >
>
> I think you and I have a common understanding on this point. I only
> brought the root user in because the primary concern seems to be
> "ownership" of the line, and I thought 'root' could arbitrate that.
>

Even root cannot access a line held by gpioset, at least not via the
GPIO uAPI.  Root would have to kill the process holding the line first.

> > >
> > > No - not referring to sysfs... and I'm not sure I'm following your
> > > argument here. But the only point I'm trying to make is wrt
> > > 'persistence': First, I'll assume that you are saying that gpioset has
> > > a role to play in persistence, and that it does not delegate the
> > > persistence question to the driver. Under that assumption, I am
> > > suggesting that another model for persistence is as I outlined above.
> > > And I'll ask again, "Is there a reason that model could not work?"
> > >
> >
> > I'm sorry, I'm not sure what *that model* is. Gpioset has no role in
> > persistence because it's merely a wrapper around libgpiod which is a
> > wrapper around the kernel uAPI which - by design - offers no
> > persistence.
>
> Well - we're back to 'square one' it seems. There must be persistence
> in GPIO control. It gets back to my example with the bedroom light.
> Do you agree that persistence must exist in GPIO control?
>
> > FYI I understand the need for a user-space GPIO authority that's more
> > centralized and am working on a DBus daemon that will become exactly
> > that. However my cup runneth over so it'll be some time before it's
> > done. :(
> >
>
> So - does that mean that we're going to have to wait for version 3 (or
> 4?) of libgpiod to get something that provides persistence of GPIO
> control?
>

And there is that tone again...

No, AIUI this will be added to libgpiod or be a separate component.
No API changes involved and so no major version bump.

These things always take longer than you would like, and the gpioset
interactive mode is partly my attempt to provide an interrim solution
until the daemon is available.

> I apologize if this sounds "short", but if we cannot agree that
> persistence is fundamental to GPIO control, then I'm at a loss for
> words.
>

I would rather focus on providing a solution to your problem, whatever
that actually is, rather than arguing over whether the existing options
are sufficiently persistent, or what persistence even means in this
context.

The underlying issue is that the post-release behaviour is not clearly
defined across the GPIO driver interface. IIRC there has been some
discussion on signalling to the driver that it should not alter the line
post-release (on second thought maybe I'm thinking of the reading the
input/output buffer distinction), but if that were to go ahead it needs
to be done in a way that is backwardly compatible, all the way out to the
ABI, and involves updating ALL the drivers to suit.  All that is a
non-trivial task, i.e. you are looking at a butt ton of work.
It is therefore worthwhile to examine the alternatives.

So, what exactly is your problem and how does that that absolutely require
"persistence" to solve?

Cheers,
Kent.