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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, May 17, 2024 at 2:37 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Fri, May 17, 2024 at 12:53:36PM +0200, Bartosz Golaszewski wrote:
> > On Wed, May 15, 2024 at 4:14 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > On Wed, May 15, 2024 at 06:54:15AM -0700, Bartosz Golaszewski wrote:
> > > >
> > > > I think the code should go into ext/, the gpiod-ext.h header can go right next
> > > > to gpiod.h in include/ and the examples can be in the same examples/ directory,
> > > > just call them something_something_ext.c to indicate they use the simpler API.
> > > >
> > > > Does that sound right?
> > > >
> > >
> > > At the moment I've made the code a conditionally compiled block in
> > > line-request.c, so it can directly use the line-request internals.
> > > Pretty sure that can be changed to use the core API, but isn't pimpl within
> > > the library itself a tad extreme?
> >
> > I have a strong preference for that code to live in a separate .so
> > file (and by extension - a separate compilation unit).
> >
>
> 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.

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

Bart

> Cheers,
> Kent.
>
>