You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a GPIO pin's state changes (a button is pressed, or whatever), the CPU gets an interrupt, and the kernel is notified
The kernel checks if anyone is registered to be alerted of that pin's state change
If so, they have a dedicated queue that the event will be added to
Importantly, this queue is per-process.
As in, when our Rust application starts up, and uses gpio_cdev to register to be notified about a pin state change with:
let handle = chip.get_line(N)?.request(LineRequestFlags::INPUT,0,"read-input")?;
The kernel sets up a queue specifically for this process, for this one line.
The alternative, which I'm really hoping isn't the case, is that there's one queue per line that the kernel maintains, and when your Rust application starts, and registers to be notified, the queue may already have events in it that may potentially need to be discarded.
The text was updated successfully, but these errors were encountered:
The kernel has a queue per LineRequest which are not shared between processes. You should even be able to have multiple per process if you have a use case for that.
Just looking for a bit of clarification here.
From what I understand, this is how it works:
Importantly, this queue is per-process.
As in, when our Rust application starts up, and uses
gpio_cdev
to register to be notified about a pin state change with:The kernel sets up a queue specifically for this process, for this one line.
The alternative, which I'm really hoping isn't the case, is that there's one queue per line that the kernel maintains, and when your Rust application starts, and registers to be notified, the queue may already have events in it that may potentially need to be discarded.
The text was updated successfully, but these errors were encountered: