Re: [libgpiod][PATCH 3/7] tests: event: extend test coverage for reading multiple line events at once

[Bartosz Golaszewski <brgl@xxxxxxxx>]

czw., 19 gru 2019 o 17:19 Bartosz Golaszewski <brgl@xxxxxxxx> napisał(a):
>
> czw., 19 gru 2019 o 15:36 Kent Gibson <warthog618@xxxxxxxxx> napisał(a):
> >
> > > > >
> > > > > I'm not sure I understand. We can't have two event fd's for the same
> > > > > line. Or are you thinking about setting up a second line, generating
> > > > > events on it and consuming them so that we can rely on the timing to
> > > > > make sure the events were registered for the first one too?
> > > > >
> > > >
> > > > I was thinking of two event fds on the one line, and you are
> > > > correct, there can only be one, so that wont work.
> > > > Wrt using two lines, I'm not sure ordering can be guaranteed as you
> > > > end up with two separate debugfs writes...
> > > >
> > >
> > > Yeah I gave it a spin and it turns out it's not reliable - some events
> > > still get dropped albeit less than without any syncing. The usleep()
> > > calls are still better than this. Any other ideas? I agree this is not
> > > optimal, but couldn't come up with anything else.
> > >
> >
> > The two options I can think of are getting the debugfs write
> > to block until the simulated interrupt has been serviced, or adding a
> > multi-line set to the mockup so the two lines can be set simultaneously.
> > I'm not sure the first is possible.
> > And the second wont help if it results in two interrupts unless the
> > order the interrupts are serviced is guaranteed.
> > Either way it seems like a whole lot of work just to remove the sleeps,
> > so the sleeps seem like a reasonable workaround :(.
> >
>
> Now when I looked at gpio-mockup again I'm under the impression that
> the interrupt should be fired from the set() callback, not from the
> debugfs write callback. But this is a minor detail and it won't help
> here.
>
> Anyway, I'm really not sure how to do it any differently. We can also
> be less strict in user-space - we can schedule, let's say, 16 events
> without sleeps and not really verify the number of read events - just
> check if it's bigger than 1 and that what we read are actual events
> (valid event_type).
>
> Bart

If there are no other issues, I'll apply this series as is (with some
comments explaining why we do this). We can improve the tests later
once we have something better in place in the kernel. For now - they
are pretty stable, I've been running them a lot and never saw an issue
with missed events.

Bart