Re: [libgpiod] Rethinking struct gpiod_line_bulk

[Kent Gibson <warthog618@xxxxxxxxx>]

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