Re: [libgpiod][RFC] helper functions for basic use cases

[Kent Gibson <warthog618@gmail.com>]

On Wed, May 22, 2024 at 12:59:39PM +0200, Bartosz Golaszewski wrote:
> On Fri, May 17, 2024 at 2:37 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> >
> > Oh, I agree - that makes total sense.  The direction I was headed felt wrong,
> > so I figured I must've misunderstood what you meant.
> >
> > I'll re-organise it into a separate unit.
> >
> > Does that unit have to act through the core API, or can we give it
> > access to the internals?
>
> If we can avoid it accessing the internals, that would be awesome.
> Unless you hit a road-block, please try to keep the core separate.
>

If you want the ext functions to store config then that would rule out the
shortcut constructors returning a gpiod_line_request.

I was thinking that the ext could be a friend of core and get access to
some things not generally accessible, in this case allowing ext to store
the config inside the request.

Without that, the two options we have is to rebuild the config from line
info, which you don't like, or wrapping the gpiod_line_request and have
the wrapper provide an accessor to the contained gpiod_line_request if
the user wants to use core API, which I'm not thrilled about.
But that seems to be the only option.

> > And where do you stand wrt the idea of adding a config pointer to struct
> > gpiod_line_request itself?
> >
>
> We'd need to make a deep copy, otherwise it could be destroyed and the
> pointer would be left dangling, right?
>

No, as the config is constructed and added by ext - the user can't actually
see it.  It would only be accessed indirectly via the ext functions.
If using only the core API then it would always be NULL.

Well unless we were to provide accessors to make it accessible to the
user, and then which way to go would be open to debate.  There are other
functions in libgpiod that pass ownership, so copying isn't the only
option. I haven't put much thought into that though, as I wasn't planning
to go there.

Cheers,
Kent.