On Tue, Oct 13, 2020 at 2:28 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > 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. > Ah right! Yes, you're right. Let's ditch this then and return events referencing lines on which they occurred. Bartosz