Can anyone tell me the best way for kernel modules (e.g. irq handler) to
inform user code that an interrupt has occured. One option is of course to
use signals but this doesn't seem particularly effective nor robust.
Instead, I would suggest that you implement a socket family to produce
this mechanism. With a socket family, interrupt events can be queued up
to user space, and each entry in the queue can contain whatever
arbitrary data you like that your user space "interrupt handler" may
need to properly service the interrupt. This mechanism allows you to
avoid the need for an interlock to prevent the loss of interrupts.
Also, if servicing an interrupt requires the access of read-clear
registers, you can insulate that access to your real, kernel space
handler, by simply packing the appropriate register values in the skb
that you queue to the socket family. Then all thats left to do in user
space is create a thread that selects on an open socket descriptor
opened against your socket family.
> Can anyone tell me the best way for kernel modules (e.g. irq handler) to
> inform user code that an interrupt has occured. One option is of course to
> use signals but this doesn't seem particularly effective nor robust.
>>I would suggest that you implement a socket family to produce
> When I needed this kind of functionality (transferring hardware
> events to user space) I simply made a kernel driver for a /dev/pulse
> character special device (Major device 10, minor device selected
> from 240-255 "Reserved for local use"). It wasn't hard to grab
> code from the Rubini book and drivers/char/nwbutton.c and make
> something that works. Sounds simpler than inventing a whole new
> socket family.
> - Larry
attached patch is a second try of IRQ handling code consolidation.
This is a common part (tested and works on i386).
Andrey Panin | Embedded systems software developer
2. Optra E 3