Re: [libgpiod] gpiomon loses events

[Kent Gibson <warthog618@gmail.com>]

On Tue, Sep 15, 2020 at 10:34:31AM +0300, Maxim Devaev wrote:
> > The bug was introduced in libgpiod v1.5 so, depending on your
> > circumstances, I would revert to an earlier libgpiod or apply my patch.
> > ...
> 
> Is this behavior documented somewhere? It's a complete surprise to me
> that this is how it works. I expected to lose the old events. It seems
> to me that for software that catches edge, the loss of new events is a
> serious problem, since it can lead to a desynchronization of the
> physical state of the pin and the user's information about it. For
> example, if event 16 was falling and event 17 was rising, and the
> signal stopped changing and remains at 1, the kernel will tell us that
> it was only falling (i.e. 0), while the real state will be 1.
> 
> If we lose events in any case, then in my opinion it is much more
> important to keep the current state, not the past. I can't think of a
> case where the loss of old events can lead to problems, but the
> desynchronization of the current state actually means that the
> software can make the wrong decision in its logic based on the
> driver's lies. Yes, this would be a breaking change, but it seems to
> me that it is the current behavior that is incorrect. Don't get me
> wrong, I don't insist on it. If this decision was made for certain
> reasons, I would like to understand where I am wrong.
> 

I agree - it makes more sense to discard the older events.
The existing behaviour pre-dates me, so I'm not sure if it is
intentional and if so what the rationale for it is.

And I'm still trying to think of a case where it would be harmful to
change this behaviour - what could it break?

> I see a specific workaround and for this behavior, when the read
> timeout occurs, I can re-read the batch of all lines to check if the
> state has changed. But it partially makes it meaningless to wait for
> events. I still have to manually check if anything is lost or if the
> driver has started lying to me. Here the example:
> https://github.com/pikvm/kvmd/blob/7cdf597/kvmd/aiogp.py#L102
> 
> The fact is that after reading the presentation from Bartosz
> Golaszewski and seeing the line "Events never get lost!", I was
> impressed and satisfied, but the situation was not so happy:
> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
> 

To be fair, the slide in question is comparing SYSFS with CDEV.
With the SYSFS API it is impossible to queue events in the kernel.
CDEV can provide a queue, it is even in the slide, but all queues
are finite and so can only help iron out bursts - they aren't magic.
On average you need to be able to service the events at the rate
they are arriving or the queue will eventually overflow.

> BTW what about unpaired falling-rising events? Is this how it should be?
> 

If you are losing events then this is what you will get.
No attempt is made in the kernel or libgpiod to keep rising and falling
events paired (until debounce support in GPIO CDEV uAPI v2 arrives).

What is your use case?  Are you seeing these problems in practice or
only because you are generating events faster than you service them
for testing?

Cheers,
Kent.