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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
