irq handling- kernel vs. user code

irq handling- kernel vs. user code

Post by Antti Innama » Thu, 26 Jun 2003 16:56:17



Hi,

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.

Thanks,
Antti

 
 
 

irq handling- kernel vs. user code

Post by Neil Horma » Thu, 26 Jun 2003 20:32:00


Signals are an intuative method for doing this sort of work, but in my
opinion, they tend to be more trouble then they are worth.  the signal
handler is prone to loosing signal events, and consequently interrupts,
which means you have to implement an interlock mechanism between your
kernel space code and your user space code.  The interlock has to
disable interrupts until the last interrupt is serviced, which can cause
performance problems on your device. Also, people implementing this
method tend to treat the signal handler as a sort of bottom half for
their interrupt handler, and they wind up spending large amounts of time
in the signal handling context, which can cause various problems in the
rest of your code.  I would recommend avoiding this implementation

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.

HTH
Neil


> Hi,

> 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.

> Thanks,
> Antti


 
 
 

irq handling- kernel vs. user code

Post by Pete Zaitce » Fri, 27 Jun 2003 00:35:10



> Signals are an intuative method for doing this sort of work, but in my
> opinion, they tend to be more trouble then they are worth. [...]
> 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. [...] 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.

Neil is right on the money, only I'd normally implement a character
device instead of a socket. It's about the same thing, only it's
better documented and you can do mmap in case of bulk data.

-- Pete

 
 
 

irq handling- kernel vs. user code

Post by Larry Doolittl » Sat, 28 Jun 2003 00:33:22



> I would suggest that you implement a socket family to produce
> this mechanism.

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

 
 
 

irq handling- kernel vs. user code

Post by Neil Horma » Sat, 28 Jun 2003 02:20:01




>>I would suggest that you implement a socket family to produce
>>this mechanism.

> 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

I've used the character driver method as well, and it is actually a bit
simpler to implement.  I chose to use the socket interface primarily
becuase I typically write device drivers for various networking devices
(switch fabrics, nP's, etc.) and on interrupt I receive control data as
a packet.  The socket family in my case was the more intuative design.
Sorry, probably should have thought of that before I posted.
Neil