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

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

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

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

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

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.

Best Rgds,
~S