Why is the /dev/gpiochip line event kfifo so small?
Hi,
I was looking into using the /dev/gpiochip API to detect pulses. In my application, the crucial bit is to precisely identify the start time of the pule and the API mostly helps doing that by providing high precision kernel timestamps. However, it stuffs them into a kfifo with 16 entries. When your hardware is not properly debounced (which it always should, but often isn't), that space can fill quickly. Is there a reason to limit the API to such a small number of events?
A single event is 16 bytes. So for every line, we incur 256 bytes of kfifo space. This space is only incurred for lines that are actually being watched. It seems to me that bumping up this size would not hurt badly. Non-realtime applications could then read events after-the-fact with a smaller risk of missing ones. I've encountered a full kfifo a number of times now.
Helmut
Quoted 10 lines · Helmut Grohne
Hi,
I was looking into using the
/dev/gpiochipAPI to detect pulses. In my application, the crucial bit is to precisely identify the start time of the pule and the API mostly helps doing that by providing high precision kernel timestamps. However, it stuffs them into a kfifo with 16 entries. When your hardware is not properly debounced (which it always should, but often isn't), that space can fill quickly. Is there a reason to limit the API to such a small number of events?
Quoted 7 lines
A single event is 16 bytes. So for every line, we incur 256 bytes of kfifo space. This space is only incurred for lines that are actually being watched. It seems to me that bumping up this size would not hurt badly. Non-realtime applications could then read events after-the-fact with a smaller risk of missing ones. I've encountered a full kfifo a number of times now.
Debounce support is added in GPIO uAPI v2, as is configurable event buffer size. And sequence numbers in events to help detect buffer overflows.
Btw, uAPI v2 is currently in train to be included in Linux v5.10.
Cheers,
Kent.