Interrupt-Handling in User Space

Interrupt-Handling in User Space

[Clifford Wolf]

Hi,

afaics there is no mechanism in the official kernel tree to handle
interrupts in user space yet. I'd need that for an embedded project I'm
woking on atm and are so far not sure if I'm going to implement such a
generic interface or just write a simple driver that does the job for my
application. So I'd like to find out what the chances are that such a
feature will get accepted in the official kernel..

Rationale: I'm not a fried of 'device drivers in userland'. But sometimes
one wants to talk to the hardware directly without anything like a 'device
driver' at all (e.g. for hardwaretesting, prototyping and debugging). In
my application I have my hardware block memory mmapped in the application
using /dev/mem to avoid additional copying steps between kernel and
userland. All I need now is an easy way to handle interrupts in my
application.

My plan is to extend drivers/char/mem.c to implement an additional /dev/irq
device file with the following ICOTLs:

IOCTL_IRQ_REGISTER
	Integer argument: Interrupt Number
	Must be the first ioctl issued after opening the device file. It
	registeres an interrupt handler which is associated with the fd
	and gets unregisteredwhen the fd is closed.

IOCTL_IRQ_AUTHORITIVE
	Argument is ignored
	Usually the interrupt handler returns IRQ_NONE. After this ioctl
	has been called it returns IRQ_HANDLED instead.

IOCTL_IRQ_FLUSH
	Argument is ignored.
	Returns the number of interrupts since the last IOCTL_IRQ_FLUSH,
	IOCTL_IRQ_WAIT or read() call.

IOCTL_IRQ_WAIT
	Argument is ignored.
	Returns without blocking if there have been any interrupts since
	the last IOCTL_IRQ_FLUSH or IOCTL_IRQ_WAIT call or blocks until
	the next interrupt otherwise.
	Returns the number of interrupts since the last IOCTL_IRQ_FLUSH,
	IOCTL_IRQ_WAIT or read() call.

Reading from the device file has the same effect as calling IOCTL_IRQ_WAIT
when reading in blocking or IOCTL_IRQ_FLUSH when reading in non-blocking
mode. When the read buffer len is 4 or more and there have been any
interrupts the first 4 bytes are filled with the number of interrupts
since the last IOCTL_IRQ_FLUSH, IOCTL_IRQ_WAIT or read() call and 4 is
returned. Using select() or epoll() will also be possible. Reading returns
zero (EOF) when there haven't been any interrupts and the read is
non-blocking.

What do you think? Any arguments against approach? Does anyone else also
feel the need for something like that in the kernel?

yours,
 - clifford

-- 
Once you have something that grows faster than education grows, you're
always going to get a pop culture. -- Alan Kay

Re: Interrupt-Handling in User Space

[Thomas Gleixner]

On Sat, 2007-05-05 at 21:17 +0200, Clifford Wolf wrote:
> afaics there is no mechanism in the official kernel tree to handle
> interrupts in user space yet. I'd need that for an embedded project I'm
> woking on atm and are so far not sure if I'm going to implement such a
> generic interface or just write a simple driver that does the job for my
> application. So I'd like to find out what the chances are that such a
> feature will get accepted in the official kernel..

Please take a look at drivers/uio, which is currently in -mm and on the
way to mainline.

	tglx

Re: Interrupt-Handling in User Space

[Sam Ravnborg]

On Sat, May 05, 2007 at 09:55:33PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-05-05 at 21:17 +0200, Clifford Wolf wrote:
> > afaics there is no mechanism in the official kernel tree to handle
> > interrupts in user space yet. I'd need that for an embedded project I'm
> > woking on atm and are so far not sure if I'm going to implement such a
> > generic interface or just write a simple driver that does the job for my
> > application. So I'd like to find out what the chances are that such a
> > feature will get accepted in the official kernel..
> 
> Please take a look at drivers/uio, which is currently in -mm and on the
> way to mainline.

UIO is featured in latest LWN kernel edition (subscribers only until Thursday).
That may help to get an overview.

http://lwn.net

	Sam

Re: Interrupt-Handling in User Space

[Alan Cox]

> afaics there is no mechanism in the official kernel tree to handle
> interrupts in user space yet. I'd need that for an embedded project I'm

Its basically not possible to do with most hardware because you get
deadlocks when there are shared interrupts.

However see drivers/uio in the current GIT tree (or recent -mm kernels),
that assumes you write a truely minimal IRQ handler/board driver in the
kernel and it then exposes the memory spaces and IRQ stream to user space.