Messages in this thread | | | Date | Tue, 14 Sep 1999 14:52:43 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: Interrupts for userspace |
| |
--------- 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/
| |