I am working with BeagleBone Black which has gpio pins configurable via kernel module. In educational purposes I am developing a module able to attach an interrupt on gpio state change.
My idea was that I have an interface in Python which sends pid to device(kernel module) and thus waiting for the signal on hardware interrupt from kernel space to perform a certain action(method).
So the logic goes as follows:
- Python process sets a handler function callable on signal SIGIO
- Python process sends his pid and gpio pin id to kernel module
- Kernel module receives a pid and gpio id from python process; registering gpio pin to specific irq number in IVT table(accomplishing this with simple kernel function) and registering a kernel handler function for this irq number
- On hardware interrupt(gpio state has changed) the kernel handler function is invoked and the (python) task is found via pid associated to irq number and signal is sent as SIGIO to Python process
- Python process receives this signal and the python handler function is invoked
This works quite well, but I run to a problem, what if Python process has several handlers for different gpio pins. Than all handler functions are invoked, which is a bad behavior. I searched online and found this question where the guy is advised strongly not to do this kind of kernel-user space communication and to use polling as a way to learn about the event happened.
As the alternative I am supposed to poll from python process on specific gpio pin. The question is, isn't the interrupt technique better? I mean this is just a common logic, the python process isn't waiting(busy) for gpio state to change, when hardware interrupt is invoked he is than and only than informed about the event and thus only than uses cpu time.
I probably don't understand what is going on under the hood, and that's why not seeing the polling technique as the way to do it.
I am also backed up with some working code, so if it needs some clarification I can show it.
Thanks for your help.