From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
linux-gpio <linux-gpio@vger.kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [libgpiod] Rethinking struct gpiod_line_bulk
Date: Wed, 21 Oct 2020 16:29:17 +0800 [thread overview]
Message-ID: <20201021082917.GA22853@sol> (raw)
In-Reply-To: <CAMRc=Mf9EEjVFSvguGzem2awf36DOJoib-nwTrJr6G1xzjT5rg@mail.gmail.com>
On Wed, Oct 21, 2020 at 09:33:03AM +0200, Bartosz Golaszewski wrote:
> On Wed, Oct 21, 2020 at 12:24 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Tue, Oct 20, 2020 at 05:53:31PM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Oct 20, 2020 at 5:06 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > >
> > [snip]
> > > > >
> > > > > I'm now actually leaning more towards making it opaque but I need to
> > > > > find a way to make gpiod_line_bulk_foreach_line work with hidden bulk
> > > > > struct.
> > > > >
> > > >
> > > > Why not just drop it in favour of gpiod_line_bulk_foreach_line_off()?
> > > >
> > >
> > > The one with the line being supplied to the user automatically is more
> > > elegant. If anything - I'd prefer to drop
> > > gpiod_line_bulk_foreach_line_off(). Callbacks as suggested by Andy is
> > > a good idea - something like what GLib does in a lot of helpers for
> > > lists etc.
> > >
> >
> > Not sure what you mean here - they both return the line, the difference
> > is how they store the loop state, with gpiod_line_bulk_foreach_line()
> > exposing the bulk->lines array via the lineptr. That is the source of
> > your problem if you go opaque - that array becomes hidden, as it
> > probably should be.
> >
>
> No idea what I meant either. :)
>
> When using a function with a callback we no longer need the user to
> supply the memory for storing the loop state - it can be stored in the
> stack frame of said function - so the callback should only take the
> line as argument (+ void * user data) and the user can store the loop
> state however they like. This is how I see it.
>
That makes sense - if you are going opaque then the callback is cleaner.
Will the callback have any return code, say to trigger a break from the
loop?
Cheers,
Kent.
prev parent reply other threads:[~2020-10-21 8:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 15:15 [libgpiod] Rethinking struct gpiod_line_bulk Bartosz Golaszewski
2020-10-12 15:21 ` Andy Shevchenko
2020-10-13 0:52 ` Kent Gibson
2020-10-13 7:45 ` Bartosz Golaszewski
2020-10-13 8:53 ` Kent Gibson
2020-10-13 12:05 ` Bartosz Golaszewski
2020-10-13 12:27 ` Kent Gibson
2020-10-13 12:53 ` Bartosz Golaszewski
2020-10-19 13:31 ` Bartosz Golaszewski
2020-10-19 16:21 ` Kent Gibson
2020-10-20 10:47 ` Bartosz Golaszewski
2020-10-20 11:05 ` Andy Shevchenko
2020-10-20 15:05 ` Kent Gibson
2020-10-20 15:53 ` Bartosz Golaszewski
2020-10-20 22:24 ` Kent Gibson
2020-10-21 7:33 ` Bartosz Golaszewski
2020-10-21 8:29 ` Kent Gibson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201021082917.GA22853@sol \
--to=warthog618@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=geert@linux-m68k.org \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).