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: Tue, 13 Oct 2020 20:27:53 +0800 [thread overview]
Message-ID: <20201013122753.GA217897@sol> (raw)
In-Reply-To: <CAMRc=McbDOQ1=SBfj6DbsMQ+fcRtZ9n4eiEqVeY74frcOM=wVw@mail.gmail.com>
On Tue, Oct 13, 2020 at 02:05:35PM +0200, Bartosz Golaszewski wrote:
> On Tue, Oct 13, 2020 at 10:53 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Tue, Oct 13, 2020 at 09:45:04AM +0200, Bartosz Golaszewski wrote:
> > > On Tue, Oct 13, 2020 at 2:53 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Mon, Oct 12, 2020 at 05:15:25PM +0200, Bartosz Golaszewski wrote:
> > > > > Hi!
[snip]
> > > > >
> > > > > in the kernel) in struct gpiod_line and chain the lines together with
> > > > > struct gpiod_line_bulk containing the list head. That would mean only
> > > > > being able to store each line in a single bulk object. This is
> > > > > obviously too limiting.
> > > > >
> > > >
> > > > I don't think I've ever gotten my head fully around the libgpiod API,
> > > > or all its use cases, and I'm not clear on why this is too limiting.
> > > >
> > >
> > > For instance: we pass one bulk object to gpiod_line_event_wait_bulk()
> > > containing the lines to poll and use another to store the lines for
> > > which events were detected. Lines would need to live in two bulks.
> > >
> >
> > Ahh, ok. So you want to keep that? I prefer a streaming interface, but
> > I guess some prefer the select/poll style?
> >
>
> Yeah I wanted to keep it. Why? We allow plugging into external event
> loops by providing a helper for accessing the underlying file
> descriptor but I think we still should have some basic wrappers for
> poll(). What exactly are you referring to as "streaming interface"?
>
By "streaming interface" in this context I mean reading the events from
the fd. That stream of events retains ordering where select/poll on a bulk
doesn't.
Cheers,
Kent.
next prev parent reply other threads:[~2020-10-13 12:28 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 [this message]
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
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=20201013122753.GA217897@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).