Re: Interrupts for userspace
Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Tue, 14 Sep 1999 14:52:43 -0500 (CDT)
--------- Received message begins Here ---------
> From: Pavel Machek <pavel@atrey.karlin.mff.cuni.cz>
> Hi!
>
> > > Sorry. I of course wanted _interrupts_ to be delivered to
> > > userspace. The code to do so (I believe it was chardevice) was already
> > > posted to l-k but I can not find it :-(... I do not want to reinvent
> > > the wheel.
> >
> > You cant do it for PCI. You have to write a custom irq handler that does
> > all that is needed to clear the IRQ then posts something out
>
> BTW why not? Assuming shared interrupts:
>
> IRQ cames,
>
> my driver blocks interrupt and tells userspace
>
> userspace notices it is not its interrupt and tells kernel
>
> kernel unblocks and sends interrupt to next driver in chain
>
> As long as you don't share interrupt with disk driver (or if you have
> userspace driver pagelocked), there will not be deadlocks.
>
> Of course it will be dog slow. It will introduce incredible
> latencies. But it might even work.
Potential deadlock is caused by the userspace process:
1. interrupt arrives
2. (other drivers called)
3. user space driver called
4. userspace driver (for some reason) needs page from disk
5. kernel needs new page, needs I/O
6. hang - IRQ not dismissed.... system dead....
Granted this is a potential, not a guranteed failure. I wouldn't want
to share IRQs just because of the difficulty in debugging. Thats more
for something in final integration testing, not development, which is
all a userspace driver would be good for.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/